EJB 2.x – Entity Beans (Bean-Managed Persistence – základné fakty)

27. září 2005

•

Pre každú entity bean, ktorú vytvoríte, si máte možnosť zvoliť spôsob, akým bude jej stav synchronizovaný s podkladovou databázou. V podstate máte dve možnosti. Buď si zabezpečíte potrebný kód na prácu s databázou sami (respektíve využijete služby niektorého frameworku), alebo vytvoríte potrebné mapovanie stavových polí EB na databázové polia a zvyšok práce necháte na EJB kontajner.

Keďže oba spôsoby majú svoje výhody aj nevýhody, postupne si rozoberieme obidva. Zameriame na to, čo všetko treba vykonať na zabezpečenie perzistencie EB vo vlastnej réžii. Z toho dôvodu bude najviac priestoru venovaného mechanizmu implementácie entity beanu používajúceho Bean-Managed Persistence (BMP). Naučíme sa, čo sa od nás očakáva vykonať vo vnútri každej z callback metód, predstavených v predchádzajúcich článkoch.

Avšak predtým, ako sa do toho pustíme, je veľmi dôležité si uvedomiť, aké dopady môže mať použitie BMP a ako správne rozpoznať, kedy je tento mechanizmus tou správnou voľbou. Špecifikácia EJB 2.0 totiž kladie veľký dôraz práve na použitie druhého možného mechanizmu perzistencie Container-Managed Persistence (CMP). Takže predtým, ako sa rozhodnete pre BMP, mali by ste mať na to vážny dôvod.

Bean-Managed Persistence – všeobecne

Pri použití BMP sa obvykle rozhodujete, či použiť vlastný JDBC kód, alebo využiť služby niektorého frameworku (Oracle TopLink, CocoBase Enterprise O/R), za účelom implementácie potrebného kódu na prácu s databázami. Váš vlastný kód, alebo ten použitý v ľubovoľnom frameworku, by mal mať precíznu kontrolu nad SQL príkazmi, ktoré generuje za účelom správy perzistencie zverených objektov. Tento predpoklad je základom vhodnosti ale aj nevhodnosti použitia BMP.

Keďže tento prístup vám dáva oveľa viac voľnosti z pohľadu generovaného SQL, BMP je vhodné použiť vtedy, keď potrebujete implementovať niečo, čo dostupný mechanizmus CMP neumožňuje. Čiže máte plnú kontrolu nad tým, ako bude perzistencia realizovaná. Na druhej strane zjavnou nevýhodou tohto prístupu je, že musíte vytvoriť a spravovať oveľa viac kódu. Čiže ste oveľa viac závislí na implementovanom kóde, na rozdiel od mechanizmu CMP, ktorý je možné modifikovať aj bez problematickej zmeny aplikačného kódu.

Vo všeobecnosti je potom fakt, že BMP má potenciál byť viac náchylné na tvorbu chybového kódu. Možno je to niekedy ťažké priznať, ale každý programátor občas napíše chybový kód. Stáva sa to najmä vtedy, ak riešite určitú problematiku v oblastiach, v ktorých nie ste až tak celkom doma. Možno práve preto dospela evolúcia v oblasti vývoja softvéru do štádia, kedy je v záujme spoľahlivosti a menšej chybovosti vhodnejšie písať menej kódu. Práve preto nám Java API poskytuje triedy a rozhrania, aby sme nemuseli nanovo vynachádzať koleso. Ak sa snažíme maximálne vyťažiť s týchto tried, potom máme k dispozícii spoľahlivé a otestované základy, na ktorých sa už dá budovať, a následne sa môžeme zamerať na tie časti aplikácie, ktorým rozumieme najlepšie. EJB ide ďalej v tom, že poskytuje základy pre budovanie distribuovaných aplikácií. CMP na rozdiel od BMP ide ešte o jeden krok ďalej v tom, že redukuje množstvo práce potrebné na zabezpečenie perzistencie vašich entitných objektov.

Ďalej si treba uvedomiť, že pri použití BMP je pomerne ťažké písať taký kód, ktorý je nezávislý od konkrétnej databázy alebo aplikačného servera. Napriek tomu, že JDBC pomerne úspešne skrýva pred programátorom všetky implementačné detaily vzťahujúce sa ku konkrétnemu databázovému serveru, občas narazíte na problém, ak musíte využiť určitú špecifickú vlastnosť (napríklad automatické generovanie primárneho kľúča). Z toho vyplýva, že ak sa viac sústredíte na implementáciu perzistencie (BMP), budú vaše entitné triedy menej flexibilné.

Napriek všetkým spomenutým negatívam by som vôbec nezavrhoval BMP ako úplne nevhodné riešenie. V skutočnosti sa veľa vývojárov zhoduje v tom, že benefity, ktoré toto riešenie prináša, bez problémov zatienia negatíva. Platí to hlavne vtedy, ak použijete objektovo-relačné mapovanie (ORM), namiesto priameho písania JDBC volaní.

Napríklad spomínaný TopLink vám môže externe zabezpečiť mapovanie medzi jednotlivými vybranými stavovými premennými objektu a databázovými poliami, bez ohľadu na to, či použijete BMP alebo CMP. To znamená, že ste izolovaný od problémov pri zmenách názvov databázových polí. Samozrejme z pohľadu kódu vašich entitných tried. Framework ako je tento, obvykle spravuje rozdiely medzi jednotlivými databázovými platformami.

ORM framework a BMP

Ako som už spomenul, keď implementujete entity bean s použitím BMP, musíte sa rozhodnúť medzi použitím určitého ORM frameworku a písaním JDBC volaní priamo. ORM produkty poskytujú Java API, ktoré umožňuje ukladať objekty do databázy volaním metód konkrétnych Java objektov. Vašou úlohou je definovať prepojenia medzi triedami určenými na perzistenciu a databázovými tabuľkami, prostredníctvom nástroja poskytovaného dodávateľom konkrétneho ORM frameworku. Tieto prepojenia sú potom počas behu programu využívané na preklad stavu objektu z objektového sveta do sveta relačných databáz. Samozrejme na pozadí aj tak prebieha komunikácia s databázou pomocou JDBC, ale detaily jednotlivých volaní sú ukryté.

Každý dodávateľ ORM, ktorý podporuje BMP, poskytuje na to svoje vlastné API. To je jedna z niekoľkých nevýhod týchto nástrojov. Unikátnosť týchto API rozhraní tiež spôsobuje, že je problematické ak vôbec možné, venovať sa z určitého nadhľadu použitiu týchto ORM nástrojov aj v našich článkoch o EJB. Každý z nich je totiž svojím spôsobom unikátny. Ak sa rozhodnete používať jeden konkrétny z nich, mala by vám úplne stačiť dokumentácia poskytovaná spolu s nástrojom. Preto sa tu zameriame na to, ako použiť JDBC pri implementácii BMP. Avšak nie je treba sa obávať, pretože množstvo použitých postupov sa dá aplikovať aj vtedy, ak použijete ORM produkt.