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 :-)
Názor k článku
Entity beans v JBoss
