Vlákno názorů k článku Entity beans v JBoss od VashStampede - Pres rok pracuji s EJB a CMP na...

Pres rok pracuji s EJB a CMP na aplikacnim serveru od Sunu (glassfish). Do teto technologie se pronika velice ztuha. Kdo si precetl clanek a nejspis mu dokonale porozumnel, ted asi nechape co to tu placam. Ja srovnavam tuto technologii se silou a schopnostma Oracle PL/SQL. A co jsem zatim zjistil je, ze je to slabe, nektere veci nefunguji. SQL generovane persistentnim managerem je strasne neoptimalni a clovek ma minimum moznosti jak to ovlivnit. Na ucebnicovych prikladech s tremi tabulkami to vypada vsechno nadherne. Ale tak to v praxi nikdy nefunguje. Clovek je nucen casto vytvaret vysoce konfigurovatelne produkty, kde dotazy musi byt generovany dynamicky a ne natvrdo ve zdrojaku. Databazovy model se muze menit a kod musi byt modularni. Coz znamena, ze zde nemohou byt napevno definovane vazby mezi entitami. Prezentacni logika musi mit casto vysoky stupen kontroly nad tim co se taha z databaze - bohuzel to casto taha cele entity misto jednotlivych polozek. EJB neumoznuje definovat slozitejsi relacni operace jako UNIONy a obchazi se to databazovymi view. Podle me cela technologie omezuje schopnosti databazi a hledi na ne jen jako na tabulky. Se stored procedures se zde ani nepocita. Cele to vypada jako pekne technologicke demo a nastroj pro trpelive vyvojare jednoduchych aplikaci. Na druhou stranu je pravda, ze za moje vicemene negativni zkusenosti muze neznalost a zadne proskoleni a fakt, ze jsem si musel projit snad vsemi slepymi ulickami. Docela rad si prectu neci nesouhlasny nazor.

a ja se pridam, docela souhlasim. co me navic irituje, je neuveritelne mnozstvi balastu, ktery programator vlastne ani nepotrebuje a proste ho nejak generuje, jenom aby v aplikaci byl nejaky kod... tak treba... mam POJO, ktere obsahuje priblizne ty same informace, ze kterych jde odvodit struktura DB (ci naopak), pripadne k tomu mam jeste konfigurak v xml, kde jsou tyto dve ,,stejne'' informace jeste slepene dohromady, to se pak programuje jedna basen... bez IDE to proste nejde.

"Podle me cela technologie omezuje schopnosti databazi a hledi na ne jen jako na tabulky."

V podstate ano, a jeste navic je to tak schvalne ;-). Jadrem je myslenka, ze dulezity je objektovy model datove vrstvy, a ty objekty se "proste nejak zaperzistuji" - E-R schema databaze je mene dulezite, "odvozene". EJB navic prosluly pomerne prisnym diktatem, jak ma OR mapping vypadat, ne-EJB aplikacni servery jsou na tom snad o neco lepe (neznam).
Z tohoto pojeti napr. plyne, ze jestlize mam predem dano databazove schema (E-R; napr. mam existujici 2vrstvou aplikaci), tak rozjet nad timto schematem EJB je temer nemozne. Zmena modelu (schematu) bude nutna.

"Na druhou stranu je pravda, ze za moje vicemene negativni zkusenosti muze neznalost a zadne proskoleni a fakt, ze jsem si musel projit snad vsemi slepymi ulickami."

Myslim, ze to treba bude tim, ze mate background v PL/SQL, obecneji receno, ze vas pristup k navrhu IS je "navrh databaze jako prvni", coz nefunguje, viz vyse. Pokud jste navic zkusenym matadorem zvyklym spolehat se na spoustu stored procedur, bude prechod do sveta EJB dost velkym sokem. Ja mam EJB rad (i presto, ze ladeni vykonu takove aplikace je samostatna disciplina), ale to asi jen proto, ze jsem nikdy nebyl zadny DB guru. Kdybych byval byl, asi bych to byval citil stejne, jako ted vy :-)

K tomu slouzi architekti a analitici, kteri by meli umet rozhodnout kterou technologii a kde pouzit.

Na druhou stranu, pri pouziti napr Hibernate mate moznost psat dotazy pomoci Criteria API. Pokud potrebuji slozitejsi algoritmy mam moznost bud data skladat v jave nebo je tahat z view.
Podle meho je samotna technologie pouzitelna.

Pri zmene databazoveho modelu musite tak jako tak zmenit i aplikaci. At uz je psana pomoci ORM ci jinak. Toto je spise otazka spravneho navrhu domenoveho modelu.

1) Opravdu se do toho pronika ztuha, musi se toho napsat celkem hodne, nez je videt nejaky vysledek. J2EE ma holt strmejsi ucici krivku.

2) PL/SQL je (AFAIK) natvrdo na databazi. Pokud jste nadsenec PL/SQL, tak se Vam JPA urcite libit nebude. Pokud programujete v Assembleru, odsoudite C++, pokud delate v C++, odsoudite Javu... Proste je to nejaka vyssi vrsta, ktera ma svoje plus i minus, obzvlast, kdyz je napsana obecne, aby fungovala nad vsemi relacnimi databazemi.

3) Neefektivni dotazy -- jako ktere? SELECT * from T where id=123? Dalsi dotazy (group by, havingy, county, union a tak) si prece muzete napsat pomoci NativeQuery. Pokud ho napisete dost obecne, nebude problem ani s vymenou databaze. A ve finale -- co Vam brani pouzit NativeQuery, ktere zavola Vase PL/SQL procedury a vrati to objekty (zkousel jsem, funguje bezvadne).

4) Nerikejte, ze mate kod, ktery se sam meni podle databaze. Vzdycky zmenite databazi a podle toho i kod. V tom je JPA ve vyhode -- je to na jednom miste. Pokud pouzivate ciste JDBC, tak si zmenu nemusite uvedomit a v nejhorsim pripade to spadne az v nejakem vyjimecnem pripade v ostrem behu.

5) Ano, velmi Vam chybi skoleni/cteni dokumentace/delsi zauceni. Mozna resit problemy nekde na forech (builder.cz?)...

6) Doufam, ze jsem splnil Vase ocekavani z posledni vety :-)

2) PL/SQL je (AFAIK) natvrdo na databazi. Pokud jste nadsenec PL/SQL, tak se Vam JPA urcite libit nebude. Pokud programujete v Assembleru, odsoudite C++, pokud delate v C++, odsoudite Javu... Proste je to nejaka vyssi vrsta, ktera ma svoje plus i minus, obzvlast, kdyz je napsana obecne, aby fungovala nad vsemi relacnimi databazemi.

Ufff, SQL je rozhodně mnohem vyšší vrstva než Java. Takže byste měl navázat slovy "když děláte v Javě, odsoudíte SQL". :o) Ostatně bavit se o Javě a mluvit o "vyšších vrstvách" je trošku rozpor. Ony možná ty vyšší vrstvy jsou nad Javou napsané, ale o Turingově stroji taky nebudu říkat, že je vysokoúrovňový. (On je možná s těmi "vyššími vrstvami" v Javě problém i v tom, že jsou i poněkud "široké", a to asi předřečníkovi vadí nejvíc - příliš mnoho ambicí => jejich mizerná realizace.)

Myslim ze myslel ze JPA je na vyssej urovni ako SQL z pohladu perzistencie dat. Pozorny citatel ktory si aspon precital nazov clanku tak by to asi pochopil. Chytanie za slovicka tejto diskusii asi nepomoze. A prosim nezamienajte si pojmy vrstva (z pohladu architektury aplikacie) a uroven (z pohladu abstrakcie jazyka).

Dik za odpoved. Ja tak nejak uvnitr vim, ze ta Java je dobra. Prece by se tim tolik lidi nezabyvalo, kdyby to bylo v praxi nepouzitelny. I kdyz me trochu zvyklalo prohlaseni vedeni firmy ze se vsechno bude od ted psat v Jave, protoze se to lepe prodava (nove technologie maji zvuk). Je to ponekud zvlastni zpusob jak vybirat uzitou technologii.

ad 1) J2EE neni tak tezke. Pochopit priklady a tutorialy by dokazal kazdy. Ja s tim nemam problem. Praci mi vsak komplikuji pozadavky vedeni a to ze se prepisuje existujici aplikace. To je na jednu stranu prijemne, na druhou stranu se narazi na problemy jak neco napsat v jave kdyz je to takhle v plsql+php napr. Pochopitelne by byl clovek rad, pokud by mezi technologiemi existoval nejaky jednoznacny preklad. A to neni.. Nekdo tu psal, ze prepisovat existujici aplikaci si vyzada zmenu modelu. S tim musim souhlasit. Bohuzel si takovy luxus moc dovolit nemuzu.

ad 2) Jak jsem rikal, od Javy a odeme se tu chteji obcas vlastnosti, ktere vyssi vrstva nedovoluje (relacni db ma silnejsi "vyjadrovaci schopnosti" nez objektove).

ad 3) Jednoduche dotazy to prave umi dobre. Ale efektivni dotazy jsou trochu slozitejsi. Obcas koukam do logu a vidim, ze se to na kazdy persistentni objekt selektuje zvlast.. Misto aby to pouzilo join, podminku, nebo neco.. pritom bezecne vim ze by to slo. A tak hledam, jak to postelovat anotacema. Nakonec to vzdam, protoze se to nejdriv musi cele napsat a pak se to teprve nejak zoptimalizuje. Pres native query se neziskaji persistentni objekty (pokud se nepletu). Nakonec by to mohlo skoncit tak, ze budeme pouzivat jen native query. Takze se tomu zatim vyhybame, kdyz to jde.

ad 4) I tak to muze fungovat. Kod se nezmeni v db pribude sloupecek (podle prani konkretniho klienta) a na frontendu se neco pripise do konfiguraku. Vsechen balast mezi tim (firemni framework), ktery to bali, kontroluje, inseruje, updatuje zustane. Takove schema se libi vedeni.

ad 5) souhlas. Hodne veci uz je treba vyreseno. Takze casto brousim po ruznych forech. Ty technologie, protoze jsou tak komplikovane, obsahuji i hodne chyb, ktere cloveku na dlouhou dobu zamotaji hlavu.. Urcite jsem uz i na nejake narazil.

ad b) ano. dik.