Vlákno názorů k článku
UJO Framework pro Javu od palko - Musim rict ze mi unika k cemu by mel...

Musim rict ze mi unika k cemu by mel tento framework slouzit, co je na nem revolucniho a jak ma dosahovat lepsiho performance.

V cem je lepsi UJO Object pred clasickou beanou (POJO)? Kod POJO mi pripada jednodussi a prehlednejsi nez implementace nejakeho ciziho rozhrani pripadne extend z nejakeho ciziho objektu. Set a Get metody krome nastaveni hodnoty casto slouzi k validaci (korekci) vstupnich (vystupnich) parametru. Predpokladam ze udelat toto v UJO properties znamena prepsat metody vaseho UJO objektu pro kazdy parametr zvlastni trida…

Revolucni: co je na ukladani objektu do mapy revolucniho? to snad lze uz od javy 1.1. Akorat ze s javou 5 mate i kontrolovani typu pri kompilaci. Jen pripominam ze to je pouze pri kompilaci a nikoli v runtime. Klasicke POJO ale ma to same dokonce i v runtime.

Performance: memory footprint UJO objektu musi byt radove vyssi nez u POJO (pouziti hashmap implementovani predka … ). Stejne tak jako kazde volani pro nastaveni (cteni) hodnoty musi byt zakonite pomalejsi nez u POJO. Ze serializace do xml je rychlejsi je dano tim nez nemusite delat introspekci objektu ale jenom vypisete hodnoty z mapy. To vzhledem k vetsi pametove narocnosti a k tomu ze jendoduche zapsani nebo cteni hodnoty bude radove pomalejsi mi neprijde jako vyhra. Nezminuji to ze v pripade pouziti mapy JIT compiler nejspis neudela takove optimalizace jake by mohl pri pouziti POJO.

Nechci zbytecne hanet cizi praci jen prijde ze vasemu frameworku davate privlastky ktere mu neprislusi …

… k cemu by mel tento framework slouzit
Oznámení se týká především nové implementace ORM nad UJO objekty, stejně tak jako i výše zmíněné vlastnosti.

•  – jednoduše lze překopírovat atributy jednoho objektu do druhého
•  – klonování objektu do zvolené hloubky
•  – k dispozici generický validátor a komparátor
•  – snadné vyhledání property podle jeho názvu
•  – obnova výchozích hodnot
•  – podpora textových konverzí
•  – serializace do různých formátů atd.

… Predpokladam ze udelat toto (korekci, validaci) v UJO properties znamena prepsat metody vaseho UJO objektu pro kazdy parametr zvlastni trida
Pouze překryjete metody writeValue/re­adValue v předkovi. V metodě máte možnost provádět kontrolu nejen na vybrané property, ale třeba jen pro vybrané datové typy.

… Performance: memory footprint UJO objektu musi byt radove vyssi nez u POJO
Jen připomínám, že UJO-ORM používá implementaci UJO postavenou na poli objektů (nikoli na objektu HashMap) kde výkonnostní/pa­měťové rozdíly nejsou tak významné. Situace se však zásadně změní v okamžiku, kdy do objektu musí zapisovat nějaký framework. Zápis do UJO objektů je pak řádově rychlejší, protože Java reflexi nepoužívá. Výkonu UJO objektům je věnována jedna kapitola v dokumentaci:
http://ujofra­mework.org/ja­vadoc/org/ujo­framework/pac­kage-summary.html#per­formance

… Nechci zbytecne hanet cizi praci
Díky za ohlas, člověk si pak spíše vyjasní, co by se dalo zlepšit v dokumentaci.

Zbytecna prace – Apache BeanUtils resp. ObjectUtils maji vetsinu vyjmenovanych veci nejmene 4 roky. Ostatne i drtiva vetsina „UJO“ vlastnosti se da ziskat z Apahce DynaBean tridy, kdyz na to prijde.

>> Kod POJO mi pripada jednodussi

> Máte pravdu. Výhoda UJO

je v úplně něčem jiném :-D

JavaBeany jsou vrcholem omezenosti. Zásadní výhoda UJO je v tom, že u objektu není předem dáno, jaké má atributy, a každý uživatel objektu si k němu může uložit, co uzná za vhodné. Typ objektu pak, dotaženo do extrému, není dán jeho třídou, ale atributy, které má. _To_ je teprve zajímavé!

V práci něco takového máme, včetně persistence do databáze, a flexibilita je oproti obvyklému doménovému modelu postavenému nad JavaBeanami přímo neuvěřitelná.

Nejsem si ovšem jistý, zda je persistence do databáze postavená na klasických ORM principech, to pravé – ORM je Vietnam of Computer Science a osobně ho považuju za skvělou ukázku toho, jak se po všech stránkách nemá dělat software.

A podle toho, co jsem tak letmo skouknul, je UJO-ORM totéž v bledě modrém, a výše popsanou výhodu úplně pohřbívá. Když mne vyvedete z omylu, budu rád :-)

>Zásadní výhoda UJO je v tom, že u objektu není předem dáno, jaké má atributy, a každý uživatel objektu si k němu může uložit, co uzná za vhodné. 

No musim se priznat ze jsem to moc nestudoval ale z ukazek na homepage plyne ze kazdy UJO objekt ma predem dane parametry stejne jako beany viz vsechny ty public static UJOProperty… takze teto poznamce moc nerozumim protoze to je stejne u POJO.

>každý uživatel objektu si k němu může uložit, co uzná za vhodné. Typ objektu pak, dotaženo do extrému, není dán jeho třídou, ale atributy, které má. 

Jiste dokazu si predstavit vyuziti ale pouze ve specifickych pripadech rozhodne ne jako nahradu POJO pro vsechno kde se da.

V okamziku kdy mate rozsahle projekty date prednost citelnosti a pred flexibilitou. Jendim z kamenu OOP je zapouzdrenost a rozdeleni odpovednosti v okamziku kdy mate mega flexibilni tridu ktera same nevi jake atributy bude mit jak pak o se neda hovorit o Encapsulation.

Jeste jedou dokazu si predstavi pripady kdy se takova trida bude hodit, ale jsou velmi specificke a rozhodne to neni jako nahrada za POJO…