Interval.cz

EJB 2.x - Entity Beans (Bean-Managed Persistence - zßkladnΘ fakty)

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.

Odkazy a zdroje

• Oracle TopLink - product homepage
• THOUGHT Inc. CocoBase Enterprise O/R - home page
• ORM na Wikipedia.org

Vyhledßvßnφ