Ale vysvětli mi, proč bych měl tím dictem něco ztrácet? Nevidím proto jediný důvod...
Tohle už jsem komentoval někde výše. Když už se to tedy bude řešit takhle ručně (osobně bych spíš použil spíš tu reflexi a anotace nebo kód generovaný ze specifikace), tak bych tam nechal normální datové typy toho programovacího jazyka – a jejich mapování na datové typy formátu, ať si řeší ta serializační knihovna (specifika se dají upravit konfigurací, ale nevidím důvod, proč by někdo měl být nucen to ručně programovat).
Proč už nikdy nepoužiju reflexi na serializaci: To takhle jeden kolega v kódu, který jsem přebral použil reflexy nad Enum, což ve výsledku znamenalo, že pro každou hodnotu Enumu do dalo jeden int. Hezké, krásně se to namapovalo do databáze. Pak někdo přidal nový záznam do Enumu. A první odstranil, protože ten se už neměl nikdy použít. A najednou si klienti stěžovali, že se nám mrší data.
To ovšem není chyba reflexe ale logická chyba v návrhu. Neměl to mapovat na čísla ale na textové hodnoty a k tomu tu reflexi klidně mohl použít. Případně to mohl přemapovat na jednoznakové konstanty nebo i na ta čísla, aby to v DB zabíralo míň místa, ale musel by tam mít pevně dané mapování. Taky by pomohla zkušenost třeba s C++, protože to člověka naučí ty enumy neodstraňovat a nové přidávat jen na konec.
Připravit se kvůli tomu o reflexi mi přijde škoda. Jsou např. homoikonické jazyky, které jdou v tomhle mnohem dál. Ta reflexe je tak na půl cesty, ale i tak je to velmi užitečný nástroj (spíš tedy pro tvorbu knihoven a frameworků než aplikací, tam to moc nepatří).
Nedávno jsem tady do nějaké diskuse napsal, že generování XML je někdy lepší si napsat sám, ručně, bez knihoven a hned se seběhli místní trollové, co že si to dovoluji si takovou věc psát sám… Přitom to generování XML je výrazně jednodušší než parsování (byť si nepíšeš vlastní parser asi zpracováváš SAX události nebo pracuješ nad DOMem nebo něco podobného). (jen dodávám, že cílem toho mého generátoru nebylo generování libovolného XML, ale určité podmnožiny, která je pro moje potřeby dostačující – důležité je, aby výstup bylo validní XML)
Ty výhrady k tomu generovanému kódu částečně chápu. Sám jsem s tím bojoval u Swaggeru resp. OpenAPI, kde generátor nebyl dost zralý, některé věci to nepodporovalo vůbec nebo to generovalo nesmysly… to bylo dost peklo. Něco vyřešili autoři generátoru v novějších verzích, něco jsme vyřešili sami vlastními šablonami. Ale i tak si myslím, že je většinou lepší si jednou odladit šablony/generátor než to psát pokaždé ručně. A JAXB je oproti tomu mnohem zralejší a spolehlivější technologie (byť to zemětřesení, které přišlo po Javě 8, s tím nepěkně zamávalo).
Jedna ze zkušeností, co mne v tomhle ovlivnila, byla, když jsem kdysi pozoroval lidi, kteří seděli asi dva metry od sebe, jeden psal server v Javě, druhý psal klienta v JavaScriptu a neustále řešili, že ten druhý posílá atribut s „jiným názvem“ nebo „starým způsobem“… v každé verzi byly chyby tohoto typu a pořád se na to plýtval čas a vyvolávalo to hádky. Mezi sebou si sdíleli dokument ve Wordu, ve kterém měli příklady, jak se má služba volat… Takže když mi dneska někdo tvrdí, jak nepotřebuje schéma, a že je to prý jednoduché a že stačí napsat pár příkladů a všem to bude jasné… tak se mi otevírá pomyslná kudla v kapse, protože vím, jak to dopadá. Přitom tohle se v oboru řeší od pradávna a obecně se to jmenuje IDL (interface description language). Konkrétních implementací je spousta, ale podstatná je ta myšlenka, že máš nějakou strojově čitelnou specifikaci, která definuje ten kontrakt, a ze které obě strany vycházejí.
Ale každopádně, pokud si píšeš parser ručně ale máš tu specifikaci a ne jen pár příkladů, tak je to ještě ten lepší případ.
Dělám to stejně, protože ono se to nakonec vyplatí vždycky mít to napsané ručně. Třeba když při integraci zjistíte, že protistrana posílá formát, který není v souladu se specifikací (třeba se mají posílat prázdné hodnoty jako element s nil, ale oni ten povinný element vůbec nepošlou). A když to reklamujete, dozvíte se, že jim to ale generovaný kód dělá takhle a nic s tím neudělají. Tak jsem to jednoduše vyřešil u sebe a upravil jsem parsování, a ten povinný element nebyl zas až tak povinný.
To se mi taky párkrát stalo, ale buď to šlo řešit domluvou a druhá strana uznala, že to je chyba a opravila to, aby to specifikaci odpovídalo, nebo jsme ustoupili my a upravili si to XSD nebo Swagger u sebe, a tudíž nám generátor vytvořil třídy, na které pasovala i ta původně neplatná data. Tohle se dá i případně automatizovat (tady je fajn, že XSD a WSDL jsou taky XML a dají se prohnat XSLT transformací).
Poslední příspěvky