Neskatoties uz vairākiem pozitīvajiem aspektiem, Enterprise JavaBeans arhitektūras sarežģītība kavē J2EE ieviešanu. EJB arhitektūra, iespējams, ir vienīgā J2EE sastāvdaļa, kurai tik nožēlojami nav izdevies izpildīt J2EE solījumu par pilnīgu izstrādātāju produktivitāti un pilnīgu izstrādes vieglumu. EJB 3.0 mēģina vēlreiz izpildīt šo solījumu, samazinot EJB sarežģītību izstrādātājiem. EJB 3.0 samazina programmēšanas artefaktu skaitu, ko izstrādātāji var nodrošināt, izslēdz vai samazina atsaukšanas metodes, kas jāievieš, un samazina entītijas pupiņu programmēšanas modeļa un O / R kartēšanas modeļa sarežģītību.
Šajā rakstā es vispirms aplūkoju būtiskākās izmaiņas EJB 3.0 versijā. Pirms ienirt EJB 3.0 baseinā, ir svarīgi, lai būtu pamats. Pēc tam es sniedzu augsta līmeņa skatu uz EJB 3.0 projektu un pēc tam iedziļinos piedāvātās specifikācijas specifikā, pievēršot uzmanību visām izmaiņām pa vienam: ietekme uz uzņēmuma pupiņu tipiem, O / R kartēšanas modelis, entītija attiecību modelis, EJB QL (EJB Query Language) utt.
Priekšvēsture
Divas būtiskākās izmaiņas ierosinātajā EJB 3.0 specifikācijā ir Java 5 ieviestās programmas anotācijas iespējas izmantošana un jaunais O / R kartēšanas modelis, kas balstīts uz hibernācijas režīmu.
Metadatu iespēja Java 5
Java 5 (iepriekš saukts J2SE 1.5 vai Tiger) ir ieviesis jaunu programmas anotācijas iespēju valodā. Izmantojot šo iespēju, ar šīm anotācijām varat definēt pielāgotas anotācijas un pēc tam anotēt laukus, metodes, klases utt. Anotācijas tieši neietekmē programmas semantiku, taču rīki (apkopošanas laiks vai izpildlaiks) var pārbaudīt šīs anotācijas, lai ģenerētu papildu konstrukcijas (piemēram, izvietošanas deskriptoru) vai ieviestu vēlamo izpildlaika uzvedību (piemēram, EJB komponenta stāvokļa raksturs). Anotācijas var pārbaudīt, izmantojot avotu parsēšanu (piemēram, kompilatorus vai IDE rīkus) vai izmantojot Java 5 pievienotās papildu refleksijas API. Anotācijas var definēt kā pieejamas tikai pirmkodu līmenī, kompilēto klašu līmenī vai izpildlaikā. . Visām EJB 3.0 agrīnajā projektā piedāvātajām anotācijām ir: Saglabāšanas politika gada RUNTIME. Tas nedaudz palielina klases atmiņas apjomu, bet daudz atvieglo konteineru piegādātāja un rīku piegādātāja dzīvi.
Lai uzzinātu vairāk par šo tēmu, skatiet resursus.
Pārziemot
Hibernate ir populāra, atvērtā koda O / R kartēšanas sistēma Java vidēm, kas paredzēta, lai pasargātu izstrādātājus no visbiežāk sastopamajiem datu noturības programmēšanas uzdevumiem. Tam ir arī īpaša hibernācijas vaicājumu valoda (HQL), kuras nospiedumus var redzēt jaunajā EJB QL. Hibernate piedāvā iespējas datu izgūšanai un atjaunināšanai, savienojumu apvienošanai, darījumu pārvaldībai, deklaratīvo entītiju attiecību pārvaldībai un deklaratīvajiem un programmatiskajiem vaicājumiem.
Putna lidojuma skats
Izmaiņas ierosinātajā EJB 3.0 specifikācijā var iedalīt divās kategorijās:
- Uz anotācijām balstīts EJB programmēšanas modelis, papildus EJB 2.1 modelim, kas nosaka lietojumprogrammas uzvedību, izmantojot izvietošanas aprakstus un vairākas saskarnes.
- Jaunais vienību pupiņu noturības modelis. Būtiski mainījusies arī EJB QL.
Šiem priekšlikumiem ir arī vairākas blakusparādības, piemēram, jauns klienta programmēšanas modelis, biznesa saskarņu izmantošana un uzņēmuma pupiņu dzīves cikls. Lūdzu, ņemiet vērā, ka EJB 2.1 programmēšanas modelis (ar izvietošanas aprakstiem un mājas / attālajām saskarnēm) joprojām ir derīgs. Jaunais vienkāršotais modelis pilnībā neaizstāj EJB 2.1 modeli.
EJB anotācijas
Viens no ekspertu grupas svarīgiem mērķiem ir samazināt artefaktu skaitu, kas jānodrošina pupiņu piegādātājam, un grupa ir paveikusi diezgan veiklu darbu, lai sasniegtu šo mērķi. EJB 3.0 pasaulē visa veida pupiņas ir taisnīgas vienkāršie vecie Java objekti (POJO) ar atbilstošām anotācijām. Anotācijas var izmantot, lai definētu pupiņu biznesa saskarni, O / R kartēšanas informāciju, resursu atsauces un gandrīz visu citu, kas tika definēts, izmantojot izvietošanas aprakstus vai saskarnes EJB 2.1. Izvietošanas deskriptori vairs nav nepieciešami; mājas saskarne vairs nav, un jums nav obligāti jāievieš biznesa saskarne (konteiners to var ģenerēt jums).
Piemēram, jūs paziņojat par bezvalstnieka sesijas pupiņu, izmantojot @Valsts anotācija Java klasē. Attiecībā uz valstiskām pupiņām @Noņemt anotācija ir atzīmēta uz konkrētas metodes, lai norādītu, ka pupiņu instance ir jānoņem pēc tam, kad ir pabeigts zvans uz atzīmēto metodi.
Lai samazinātu komponentam norādītās informācijas daudzumu, ekspertu grupa ir pieņēmusi a konfigurācija pēc izņēmuma pieeja, kas nozīmē, ka visām anotācijām jūs sniedzat intuitīvus noklusējumus, lai varētu secināt lielāko daļu kopīgās informācijas.
Jaunais noturības modelis
Jaunās entītijas pupiņas arī ir tikai POJO ar dažām anotācijām un pēc dzimšanas nav pastāvīgas vienības. Entītijas gadījums kļūst noturīgs, tiklīdz tas ir saistīts ar EntityManager un kļūst par daļu no neatlaidības konteksts. Noturības konteksts ir brīvi sinonīms darījuma kontekstam; stingri sakot, tas netieši pastāv līdzās darījuma apjomam.
Arī entītiju attiecības tiek definētas, izmantojot anotācijas. Turklāt O / R kartēšana tiek veikta arī, izmantojot anotācijas, un tiek nodrošināts atbalsts vairākām datu bāzei specifiskām darbībām. Izmantojot EJB 2.1, izstrādātāji izmantoja savus dizaina modeļus vai izmantoja netipiskas metodes (piemēram, automātisko atslēgu ģenerēšanas stratēģijas).
Rakšanās dziļi
Ir pienācis laiks iedziļināties EJB 3.0 agrīnajā projektā izteikto priekšlikumu specifikā. Sāksim ar visiem četriem uzņēmumu pupiņu veidiem un pēc tam pārejam pie vispārējiem priekšlikumiem par visu EJB programmēšanas modeli.
Bezvalstnieku sesijas pupiņas:
Bezvalstnieka sesijas pupiņa (SLSB), uzrakstīta EJB 3.0 veidā, ir tikai vienkāršs Java fails ar klases līmeņa anotāciju @Valsts. Pupiņu klase var ieviest javax.ejb.SessionBean interfeisu, bet tas nav nepieciešams (un parasti nebūs).
SLSB vairs nav mājas saskarnes - faktiski tas nav vajadzīgs nevienam EJB tipam. Pupiņu klase var vai nevar ieviest biznesa saskarni. Ja tas neievieš nekādas biznesa saskarnes, biznesa saskarne tiks ģenerēta, izmantojot visas publiskās metodes. Ja biznesa saskarnē būtu jāatspoguļo tikai noteiktas metodes, visas šīs metodes var atzīmēt ar @BusinessMethod anotācija. Pēc noklusējuma visas ģenerētās saskarnes ir lokālas, bet @Remote anotāciju var izmantot, lai norādītu, ka ir jāveido attālā saskarne.
Lai definētu a, pietiek ar dažām šādām koda rindām Sveika pasaule pupa. Izmantojot EJB 2.1, tai pašai pupiņai būtu vajadzīgas vismaz divas saskarnes, viena ieviešanas klase ar vairākām tukšām metožu ieviešanām un izvietošanas deskriptors.
importēt javax.ejb. *; / ** * Bezvalstnieka sesijas pupiņa, kas pieprasa tai ģenerēt attālo biznesa * saskarni. * / @Stateless @Remote public class HelloWorldBean {public String sayHello () {return "Sveika pasaule !!!"; }} Visu avota kodu, kas pievienots šim rakstam, skatiet Resursi.
Statiskas sesijas pupiņas
Stāsts ar statusa sesijas pupiņām (SFSB) ir gandrīz vienāds ar SLSB, izņemot dažus SFSB specifiskus punktus:
- SFSB vajadzētu būt iespējai inicializēt sevi (to nodrošina caur
ejbCreate ()metode EJB 2.1 un agrāk). EJB 3.0 specifikācija liecina, ka šādas inicializācijas metodes jānodrošina kā pielāgotas metodes un jāatspoguļo, izmantojot pupiņu biznesa saskarni. Tagad klientam ir pienākums izsaukt atbilstošas inicializācijas metodes pirms pupas izmantošanas. Ekspertu grupa joprojām apspriež nepieciešamību sniegt anotāciju, kas iezīmē noteiktu inicializācijas metodi. - Pupiņu piegādātājs var atzīmēt jebkuru SFSB metodi ar
@Noņemtanotācija, kas norāda, ka pēc anotētās metodes izsaukšanas pupiņu instance ir jānoņem. Atkal ekspertu grupa joprojām apspriež, vai iekārta ir nepieciešama, lai norādītu, ka pupiņu nedrīkst noņemt, ja metode nav pilnībā pabeigta.
Šis ir mans viedoklis par diviem atklātajiem jautājumiem:
- Vai vajadzētu būt inicializācijas metodes anotācijai? Mans balsojums ir "jā" - ar pieņēmumu, ka konteiners nodrošinās, ka tiek izsaukta vismaz viena no inicializācijas metodēm, pirms tiek izsauktas citas uzņēmējdarbības metodes. Tas ne tikai pasargā no nejaušām programmēšanas kļūdām, bet arī padara konteineru drošāku par SFSB gadījumu atkārtotu izmantošanu. Skaidrības labad ļaujiet man šeit pieminēt, ka nē noteiktā inicializācija metodes (piemēram,
ejbIzveidot) tiek izskatīti; ekspertu grupa tikai apsver iespēju anotācijas metodi izmantot kā inicializācijas metodi. - Vai tas ir konfigurējams, ja nenormāli izbeidzas
@Noņemtmetode nenoņem pupu instanci? Atkal mana balss ir jā. Tas tikai nodrošinās labāku kontroli pupiņu nodrošinātājam un klientu programmētājiem. Atliek tikai viens jautājums: kas notiek ar tām pupiņām, kas atzīmētas kā nē noņemts pēc neveiksmīga zvana uz noņemšanas metodi, un konkrētas instances noņemšanas metode nekad netiek veiksmīgi pabeigta? Šos gadījumus nevar programmatiski noņemt, taču sesijas taimauta laikā tie tiks noņemti.
SFSB piemēru skatiet avota kodā.
Pupiņas ar ziņām
Pupiņas, kuru pamatā ir ziņojums, ir vienīgais pupiņu veids, kam jāievieš biznesa saskarne. Šī saskarnes tips norāda ziņojumapmaiņas sistēmas veidu, kuru pupiņa atbalsta. JMS (Java Message Service) bāzes MDB šī saskarne ir javax.jms.MessageListener. Ņemiet vērā, ka MDB biznesa saskarne patiesībā nav Bizness interfeiss, tas ir tikai ziņojumapmaiņas interfeiss.
Vienības pupiņas
Vienības pupiņas ir apzīmētas ar @Entity anotācija un visi rekvizīti / lauki entītijas pupiņu klasē nē atzīmēts ar @ Pārejošs anotācija tiek uzskatīta par pastāvīgu. Entītijas pupiņu pastāvīgie lauki tiek pakļauti, izmantojot JavaBean stila īpašības vai tāpat kā publiski / aizsargāti Java klases lauki.
Entītijas pupiņas var izmantot palīgu klases, lai attēlotu entītijas pupiņu stāvokli, taču šo klašu gadījumiem nav noturīgas identitātes. Tā vietā viņu eksistence ir cieši saistīta ar īpašnieka subjekta pupu instanci; arī šie objekti nav koplietojami starp entītijām.
Atsevišķos entītijas pupiņu piemēros skatiet avota kodu.
Entītiju attiecības
EJB 3.0 atbalsta gan vienvirziena, gan divvirzienu attiecības starp entītijas pupiņām, kas var būt gan viens pret vienu, gan viens pret daudziem, gan viens pret vienu, gan no daudziem pret daudziem. Tomēr abas divvirzienu attiecību puses izšķir kā piederošo un apgriezto pusi. Īpašnieka puse ir atbildīga par attiecību izmaiņu izplatīšanu datu bāzē. Asociācijām “daudzi pret daudziem” ir skaidri jānorāda īpašnieka puse. Faktiski tā ir reversā puse, kuru norāda isInverse = true anotācijas loceklis aizmugurē ManyToMany anotācija; no tā tiek secināta īpašumtiesības puse. Vai ekspertu grupa neteica, ka tas atvieglo EJB?
O / R kartēšana
O / R kartēšanas modelis ir arī būtiski mainījies no abstraktā noturībā uz shēmas balstītās pieejas uz hibernācijas iedvesmoto. Lai gan ekspertu grupa joprojām apspriež modeli, un skaidra aina veidosies tikai ar nākamo projektu, šajā projektā ir skaidras norādes par vispārējo pieeju.
Vienam O / R kartēšana tiks norādīta pašā entītijas pupiņu klasē ar anotācijām. Pieeja ir abstraktas noturības shēmas vietā atsaukties uz konkrētām tabulām un kolonnām. O / R kartēšanas modelim ir raksturīgs vietējās SQL atbalsts; tas ir, atbalsts dziļākā līmenī, ne tikai spēja palaist vietējos SQL vaicājumus. Piemēram, kolonnu definīciju anotācija (@Kolonna) ir biedrs kolonnaDefinīcija tas var būt kaut kas līdzīgs columnDefinition = "BLOB NOT NULL".
Klienta programmēšanas modelis
EJB klients var iegūt atsauci uz pupiņu biznesa saskarni, izmantojot injekcijas mehānismu (@ Injicēt anotācija). Izmantojot tikko ieviesto @ javax.ejb.EJBContext.lookup () metode ir cita pieeja. Bet specifikācija nav skaidra par to, kā atsevišķs Java klients iegūst atsauci uz pupiņu instanci, jo atsevišķie Java klienti darbojas J2EE klienta konteinerā un viņiem nav piekļuves @ javax.ejb.EJBContext objekts. Ir vēl viens mehānisms - nesen ieviests universālā konteksta objekts: @ javax.ejb. Konteksts (). Bet atkal specifikācijā nav teikts, kā šo objektu var izmantot klienta konteinerā.
EJB QL
Vaicājumus var definēt, izmantojot @ NosauktsQuery anotācija. Divi šīs anotācijas dalībnieki ir nosaukums un queryString. Pēc definēšanas šim vaicājumam var piekļūt, izmantojot EntityManager.createNamedQuery (nosaukums) metodi. Zvanot, varat izveidot arī parastu JDBC stila (Java Database Connectivity) vaicājumu EntityManager.createQuery (ejbqlString) vai vietējais vaicājums, izmantojot EntityManager.createNativeQuery (nativeSqlString).
EJB QL vaicājumiem var būt gan pozicionālie, gan nosauktie parametri. The javax.ejb.Query interfeiss nodrošina metodes šo parametru iestatīšanai, atjauninājumu veikšanai, rezultātu uzskaitīšanai utt.
Šeit ir viens piemērs tam, kā var izveidot un izpildīt EJB QL vaicājumu:
.. .. @NamedQuery (name = "findAllCustomersWithName", queryString = "SELECT c FROM Customer c WHERE c.name LIKE: custName") .. .. @ Inject injject public EntityManager em; klienti = em.createNamedQuery ("findAllCustomersWithName") .setParameter ("custName", "Smith") .listResults (); Tālāk ir uzskaitīti daži no vairākiem QL uzlabojumiem:
