Záznam ze Vzdělávacího okénka HAVIT, kde Lukáš Michl povídal o tom, jak psát signatury metod a DTO tak, aby byl kód srozumitelný bez nutnosti číst implementaci. Přednáška pokrývá antipattern primitive type obsession, strong type values, knihovnu Vogen a best practices pro DTO.
Proč záleží na čitelných signaturách
Dobrá signatura metody prozradí, co metoda dělá, aniž by bylo nutné číst její tělo. To je klíčové pro udržovatelnost – kód se k němu vrací za dny, týdny i roky, a čím méně překvapení signatura skrývá, tím méně chyb při refaktorování vzniká. Lukáš ukazuje sérii příkladů z reálných projektů, kde nejasné signatury vedly k neočekávanému chování.
Primitive type obsession antipattern
Používání primitivních typů (string, int) všude, kde by měl být byznysový typ, vede k nejasnostem: co přesně parametr string name očekává? Je to jméno ve formátu AD, nebo zobrazované jméno? Může být null? Může být prázdný? Tyto otázky se násobí pro každé volání metody. Podobný problém nastává u ID entit – pokud jsou UserID, LoginID i EntityID reprezentovány jako int, záměna při refaktorování neprojde kompilátorem a může tiše způsobit datovou chybu.
Nullable reference types
Zapnutí nullable reference types (#nullable enable) je prvním krokem ke čitelnějším signaturám – kompilátor okamžitě sdělí, zda parametr nebo návratová hodnota může být null. Samo o sobě to ale nestačí, pokud jsou parametry stále primitivní typy bez byznysového kontextu.
Strong type values a value objects
Řešením primitive type obsession jsou strong type values – vlastní typy obalující primitivní hodnotu a nesoucí byznysový kontext i validaci. Implementují se jako C# record struct, čímž se předchází dvojité alokaci na heapu. Validace v konstruktoru zajistí, že nevalidní hodnota vůbec nevznikne – testy kontraktu pak stačí napsat jednou u definice typu, ne u každého volání metody.
Knihovna Vogen
Vogen je source-generátorová knihovna, která automaticky generuje plnohodnotné strong-typed hodnoty – včetně serializace JSON, podpory Entity Framework a možnosti přidávat validace. Bez ní by bylo ruční psaní pro stovky byznysových typů v projektu neúnosné; s Vogen stačí jedna řádka atributu nad definicí.
Strong Typed ID
Specifickým případem jsou ID entit. Knihovna StronglyTypedId řeší záměnu identifikátorů různých entit na úrovni typového systému – kompilátor odmítne předat UserId tam, kde se očekává OrderId.
DTO best practices
Suffix DTO v názvu třídy je kontrakt: objekt by měl být immutable a sloužit výhradně k přenosu dat. Lukáš doporučuje vlastnosti deklarovat s required init – přidání nové vlastnosti pak okamžitě způsobí chybu kompilace u všech míst, kde se DTO inicializuje, a zabrání tiché inicializaci výchozími hodnotami. Kombinace s konstruktorovým zápisem navíc zajistí, že kolega přistupující ke kódu poprvé okamžitě vidí, co všechno DTO nese.
Záznam ze Vzdělávacího okénka HAVIT z 6. listopadu 2025. Jirka nám ukazoval, co je nového v Entity Framework Core 10, co se hodí pro naše projekty a jak nyní funguje IN operátor (Contains()) a jeho bucketizace parametrů.
Záznam ze Vzdělávacího okénka HAVIT z 9. října 2025, kde nám Gabriela Turcajová ukazovala použití gpt-image-1 – AI modelu od OpenAI určeného pro generování obrázků. Praktická ukázka se zaměřila na zajímavý use case: generování pravděpodobné podoby dítěte na základě fotografií rodičů.
Model gpt-image-1 představuje novou generaci AI nástrojů pro práci s obrázky. Na rozdíl od starších modelů (jako DALL·E) nabízí výrazně realističtější výstupy a lepší porozumění vstupním instrukcím. Gabriela ukázala, jak model dokáže analyzovat vstupní fotografie a na jejich základě vytvořit nový obrázek kombinující rysy obou osob.
Během přednášky jsme se dozvěděli, jak s modelem pracovat, jaké jsou jeho možnosti i limity, a na co si dát pozor při formulování promptů pro generování obrázků.
Záznam ze Vzdělávacího okénka HAVIT z 25. září 2025, kde jsem ukazoval třetí způsob AI-vytěžování dokumentů – prostřednictvím all-in-one cloudové služby Azure AI Content Understanding.
V předchozích dílech série jsme si ukázali dva přístupy k vytěžování dokumentů pomocí AI: konverzi do Markdown přes Azure Document Intelligence s následným zpracováním přes LLM a přímé zpracování bitmapových obrázků přes GPT-4o Vision. Tentokrát jsme se podívali na třetí cestu – Azure AI Content Understanding, která celý pipeline (OCR, analýza struktury, extrakce dat) zapouzdřuje do jedné cloudové služby.
Co se dozvíte
Co je Azure AI Content Understanding a čím se liší od Azure Document Intelligence
Jak službu nastavit a nakonfigurovat v Azure portálu
Praktická ukázka volání REST API z C#
Porovnání všech tří přístupů k AI-vytěžování dokumentů
HAVIT Knowledge Base 