Kolik času může ušetřit framework Ujorm a proč vlastně vznikl? Nejen na tyto otázky se pokusí odpovědět následující článek.
Někdy v roce 2008 jsem měl příležitost zúčastnit se vývoje zajímavého rezervačního systému v jazyce Java pro klienta působícího v dopravě. Prezentační část se stavěla na technologii RichFaces, což byl komponentový framework postavený nad JavaServer Faces (JSF) firmy Sun Microsystems, obchodní logika byla umístěna do servisních tříd podporovaných frameworkem Spring, perzistentní vrstva se budovala na ORM frameworku Hibernate.
Implementaci předcházela analýza zkušeného analytika, většinu vývojového týmu tvořili vývojáři s mnohaletými zkušenostmi s vývojem webových aplikací v Javě. Nutno dodat, že výše uvedené technologie byly pro tým relativně nové, nicméně tento rizikový faktor byl v odhadu pracnosti zohledněn. První ohlasy byly příznivě také díky pěknému vzhledu JSF komponent s integrovanou podporou technologie AJAX. Postupem času však se však vývoj začal zpomalovat. Pracnost údržby JSF komponent (postavených na XML souborech) se zvyšovala, chyběla možnost bezpečného refaktoringu komponent, jejich znovupoužití na prezentační vrstvě bylo pracné. Překlepy vznikaly také v referencích na metody servisní vrstvy, kterou Java kompilátor nemohl z principu odhalit. V závěrečné fázi projektu pracoval na úkolu téměř dvojnásobný počet z původně vyčleněných vývojářů, přesto se projekt nepodařilo dokončit v původně plánovaném termínu a kvalitě. Tím však problémy bohužel neskončily.
Provoz na reálných datech odhalil nečekané provozní problémy. Časová úspora, kterou přineslo použití frameworku Hibernate, se postupně rozpustila během hledání nápravy chyb a optimalizaci výkonu dotazů, které fungovaly v JDBC bez problémů. Lze připustit, že příčinou některých potíží byla naše nedostatečná znalost frameworku Hibernate, proto za jeho hlavní problém považuji dlouhou dobu učení. Naopak bezproblémové bylo využití frameworku Spring, který na servisní vrstvě řídil především dependency injection a databázové transakce. Projekt byl zákazníkem nakonec akceptován, ale hořký pocit z jeho vývoje zůstal a já jsem získal dojem, že některé věci by mohly fungovat jinak. V té době jsem začal psát framework, který je dnes známý pod názvem Ujorm.
Framework Ujorm je založený na doménových objektech typu key-value, kde klíče pro zápis hodnot slouží zároveň jako property-descriptor poskytující některé služby, například jejich řetězení. Taková architektura doménového objektu umožňuje (relativně) nový přístup ke tvorbě některých algoritmů, ale na druhou stranu budí i značné kontroverze. První veřejná verze Ujorm nabízela především perzistenci do XML souborů, kterou využila desktopová aplikace jWorkSheet pro měření času odpracovaného na projektech. Později vznikl modul ORM s dialekty podporující několik databázových produktů. Nakonec vznikl modul pro integraci webového frameworku Apache Wicket. V roce 2013 jsem zveřejnil jednoduchou webovou aplikaci pro fiktivní rezervaci hotelů s názvem Demo Hotels s cílem prezentovat zajímavé využití objektů implementujících interface Ujo. Kvůli jednoduchosti projekt obsahuje pouze jednu sadu doménových objektů, vyzkoušet si ho můžete zde.
Po zveřejnění této aplikace jsem dostal příležitost přepsat projekt pro administraci reálných služeb subdodavatele. Architektura projektu se změnila, servisní služby byly přesunuty na samostatný server, komunikace probíhala přes WS SOAP, na serveru proběhla integrace služeb třetích stran, nicméně původní technologie zůstala. A teď přijde zřejmě ta nejzajímavější část příběhu: vývoj modulu, který by v technologii JSF/JPA zabral člověku odhadem 3 měsíce – trval reálně 3 týdny. Jistě bude možné napadnout odhad té větší pracnosti jako nepřiměřeně pesimistický, ani neumím vyloučit, že by to napsal někdo jiný rychleji. Pokud by však měl někdo vážný důvod ten rozdíl zpochybnit, může aplikaci Demo Hotels přepsat do technologie JSF (na šablonách XHTML) s perzistencí JPA/Hibernate a následně porovnat objem zdrojového kódu obou projektů, objem projektu Demo Hotels odhaduji právě na čtvrtinu. Malá velikost zdrojového kódu však nemusí být jedinou indicií efektivního vývoje a tak doporučuji v hotovém projektu přejmenovat atribut entity Hotel.name a doplnit nové aplikační parametry, které by umožnily uživatelům nastavovat stránkování (počet řádků na stránce) v GUI pro každou tabulku samostatně. Zatímco chyby v projektu Demo Hotels po editaci odhalí snadno i programátorský junior díky kompilátoru (pokud IDE neprovede potřebný refaktoring automaticky), v případě technologie JSF/JPA bude pracnost úprav velmi záviset na zkušenosti vývojáře.
Vypadá to, že způsob použití statických konstant s generickými typy a metodami pro čtení a zápis hodnot do doménového objektu byl ve své době unikátní. Na druhou stranu je pravda, že Ujorm může jen těžko soupeřit s konkurenty při srovnání rozsahu služeb či dokumentace. Letos uplyne deset let od uvolnění první verze ORM modulu frameworku Ujorm, od té doby byl nasazován na různých produkčních serverech bez větších provozních problémů, pokud vím. K masovému rozšíření však nedošlo.
Podla mna najvacsi problem bolo pouzit JSF mal som tu cest na niekolkych projektoch ho pouzit a len co sa trochu nestandatne pouzili komponenty spolu s ajaxom problem bol na svete. Ked to porovnam so spomínaným wicketom, kde je uplna lahoda integrovat to js knizniciu, ajaxom a podobne. Priklad hibernate - wicket = reality.sk
A nebo taky tím, že ne každý JSF pochopil. Ono taky pokud používáte Primefaces a nevymýšlíte blbosti. Hlavně většina lidí, co chce v JSF něco přihnout nerozumí JavaScriptu a obráceně pokud rozumí JS, tak nerozumí JSF. Pokud pominu JS frontendové frameworky jako React nebo Vue.js, tak jsem se pořád nesetkal s "lepší" technologií pro vývoj java frontendu.
S touto odpovědí souhlasím. Zrovinka nedávno jsem měl možnost dělat projekt s JSF a překvapilo mě, jak snadno jsem v tom celou aplikaci vytvořil. Podle mě nejdůležitější je „nevymýšlet blbosti“.
Postřehy ze světa open-source.
Přečteno 31 135×
Přečteno 20 727×
Přečteno 16 963×
Přečteno 14 475×
Přečteno 14 174×