Vlákno názorů ke článku Ujorm3: finální ORM pro JavaBeans a Records od dev_isp - Ja ted pouzivam JDBi v komercnim projektu tak...

Ja ted pouzivam JDBi v komercnim projektu tak jsem rychle porovnal pro a proti s Ujorm. Nasel jsem jedinou vyhodu Ujorm v deklaraci schema pomoci entit.

Pokud tohle nepotrebujute, a schema definuje nekdo jiny, zvolil bych JDBi ktery ma stejne vyhody a navic muzete psat DAOs pomoci anotovanych interface. (neco jako Feign client)

Myslím, že těch rozdílů je víc než jedna. Ujorm3 generuje při kompilaci (APT procesor) typované Meta třídy s Key<Employee, City> deskriptory – chybný název sloupce nebo špatný typ parametru se odhalí ihned při kompilaci, nikoli za běhu v produkci. JDBI SQL Object API přináší určitou typovou bezpečnost přes anotované rozhraní, ale samotné názvy sloupců a cesty k atributům zůstávají řetězce.

Z toho plyne i druhý rozdíl: SelectQuery generuje FROM a JOIN klauzule automaticky podle cest v metamodelu ( MetaEmployee­.city, MetaCity.name), takže JOIN není potřeba psát ručně. Metoda columns() pak vygeneruje výčet všech sloupců primární tabulky přímo z metamodelu – v JDBI lze sice použít select("*"), ale jde o prostý řetězec bez typové vazby. Třetí věc je typově bezpečný Criterion pro WHERE klauzule – podmínky se skládají programově jako binární strom objektů, ne jako SQL fragmenty. Čtvrtý bod: partial UPDATE – jde buď explicitně předat sadu Key objektů označující sloupce k aktualizaci, nebo poslat původní objekt a Ujorm3 si seznam změněných sloupců odvodí porovnáním sám; v JDBI obojí vyžaduje ruční SQL. Za páté, Java Records jsou podporovány jako first-class citizen včetně automatického mapování M:1 relací. Za šesté, na PostgreSQL jsou výsledky smíšené: Ujorm3 vede v operacích UPDATE a paměťové efektivitě, zatímco JDBI je rychlejší například u batch insertu nebo čtení entit; na H2 Ujorm3 konzistentně vyhrává prakticky ve všech metrikách. A za sedmé, Ujorm3 nemá žádné externí závislosti a jeho JAR má velikost 0,27 MB, což je přibližně pětina velikosti JDBI (1,34 MB); obě hodnoty jsou měřeny bez JDBC driveru.

JDBI samozřejmě vyhrává šíří ekosystému – pluginy pro Guava, Spring, Vavr, lepší pokrytí stored procedures a větší komunita. Anotované DAO rozhraní ve stylu Feign jsou pohodlná věc. Ale „stejné výhody" to není – záleží hodně na tom, jak moc vadí, když se chyba v dotazu projeví až za běhu.

Mate pravdu. Diky za opravdove porovnani.