OJB

Biztos mindenkinek eszébe jutott, hogy ahogy a Java alkalmazásából az adatbázist közvetlenül JDBC-vel eléri, az nem egy elegáns megoldás. Egyrészt nem igazán passzol az objektumorientált szemléletbe, másrészt csúnya, ha az SQL és a Java nyelv keveredik egymással, harmadrészt igen nagyok a hibalehetőségek.

Ezek elkerülésére több megoldás is van, egyrészt az objektumorientált adatbázis-kezelők, melyekkel a cégek általában nem rendelkeznek, és koránt sem olyan kiforrottak és robosztusak, mint a már jól bevált relációs adatbázis-kezelők, másrészt a perzisztens rétegek alkalmazása.

Én használatra természetesen ismét egy Jakarta-s project-et választottam, ami az ObJectRelationalBridge (OJB). Egyrészt mert a Jakarta név már bizonyított, tisztában vagyok a licence szabályaival és amúgy is bejön. Persze aki nem ilyen elfogult, az megnézhet egy kis összehasonlítást a létező perzisztens rétegek között. Ez a takaros lap cirka 21 Java objektum-relációs bridge összehasonlítását tartalmazza 34 szempont alapján. Ezek közül amelyikről én többel hallottam az a LiDO, Cayenne, Jakarta OJB, Castor és Hibernate.

A JDO teljes ODMG 3.0 szabvány API-t, a JDO API egy részét támogatja, ami alatt egy saját PersistentBroker API helyezkedik el, melyet én is használok. Az adatforrás lehet relációs és objektumorientált adatbáziskezelő rendszer, LDAP vagy akár XML is.

A konfigurációja (mapping) egy XML fájlal történik, ahol az objektumokat és a hozzá tartozó táblákat kell megadni. Itt definiálhatunk elsődleges kulcsot, mely automatikusan növekszik, külső kulcsot (1:n kapcsolatnál, ekkor a szülő osztály egy tömbbe vagy Collection-be tárolhatja a gyermekeket), illetve konverziós osztályokat (pl. ami boolean-ból int-et csinál). Persze utóbbiakat mi is gyárthatunk. Definiálhatunk proxy osztályokat is, melyekkel szabályozhatjuk, hogy ne töltsön be minden objektumot, melyre referencia van.

Sajnos a reverse és forward engineering és mapping-et segítő toolok hozzá gyerekcipőben járnak. Ezek segítenének vagy a Java osztályból adatbázis definíciót gyártani, vagy fordítva, illetve a mappinget automatikusan létrehozni.

Nagyon nagy mennyiségű adat esetén azonban ajánlom ezt a réteg kikerülését, vagy a proxy-k használatát, ugyanis az egyszerre több táblában való frissítés, illetve a rengeteg példányosítás jelentősen visszavetheti az alkalmazásunk teljesítményét. Pl. nagy riport készítése, napló karbantartása, stb…