Programavimas

EJB 3.0 trumpai

Nepaisant kelių teigiamų aspektų, „Enterprise JavaBeans“ architektūros sudėtingumas trukdo priimti J2EE. EJB architektūra yra bene vienintelis J2EE komponentas, kurio taip apgailėtinai nepavyko įgyvendinant J2EE pažadą padidinti kūrėjų produktyvumą ir lengvą plėtrą. „EJB 3.0“ dar kartą bando įgyvendinti šį pažadą, sumažindamas EJB sudėtingumą kūrėjams. „EJB 3.0“ sumažina programavimo artefaktų, kuriuos gali pateikti kūrėjai, skaičių, pašalina arba sumažina būtinus įdiegti atgalinio ryšio metodus ir sumažina subjekto pupelių programavimo modelio ir O / R susiejimo modelio sudėtingumą.

Šiame straipsnyje pirmiausia aprašau reikšmingiausius EJB 3.0 pakeitimus. Prieš nardant į „EJB 3.0“ baseiną svarbu turėti pagrindus. Toliau pateikiu aukšto lygio EJB 3.0 projekto apžvalgą ir tada pereinu prie siūlomos specifikacijos specifikos, atkreipdamas dėmesį į visus pokyčius po vieną: poveikis įmonės pupelių rūšims, O / R atvaizdavimo modelis, subjektas santykių modelis, EJB QL (EJB Query Language) ir kt.

Fonas

Du reikšmingiausi siūlomos „EJB 3.0“ specifikacijos pakeitimai yra „Java 5“ įdiegtos programos anotacijos priemonės naudojimas ir „Hibernate“ pagrindu sukurtas naujas O / R atvaizdavimo modelis.

Metaduomenų galimybė „Java 5“

„Java 5“ (anksčiau vadinta „J2SE 1.5“ arba „Tiger“) įvedė naują programos anotavimo priemonę kalbai. Naudodamiesi šia galimybe, galite apibrėžti pasirinktines anotacijas ir tada komentuoti laukus, metodus, klases ir pan. Anotacijos tiesiogiai neveikia programos semantikos, tačiau įrankiai (kompiliavimo laikas arba vykdymo laikas) gali patikrinti šias anotacijas, kad būtų sukurtos papildomos konstrukcijos (pvz., Diegimo aprašas) arba užtikrinta norima vykdymo trukmės elgsena (pvz., EJB komponento būsenos pobūdis). Anotacijas galima patikrinti analizuojant šaltinį (pvz., Kompiliatorius ar IDE įrankius) arba naudojant papildomas atspindėjimo API, pridėtas prie „Java 5“. Anotacijas galima apibrėžti kaip prieinamas tik šaltinio kodo lygiu, sukompiliuotų klasių lygiu arba vykdymo metu. . Visos ankstesniame EJB 3.0 projekte siūlomos anotacijos turi: IšlaikymasPolitika apie RUNTIME. Tai nežymiai padidina klasės atmintį, tačiau žymiai palengvina konteinerių tiekėjo ir įrankių tiekėjo gyvenimą.

Daugiau informacijos apie šią temą skaitykite šaltiniuose.

Hibernate

„Hibernate“ yra populiari, atviro kodo „Java“ aplinkų O / R kartografavimo sistema, skirta apsaugoti kūrėjus nuo dažniausiai pasitaikančių su duomenų patvarumu susijusių programavimo užduočių. Ji taip pat turi specifinę užmigdymo užklausų kalbą (HQL), kurios atspaudus galima pamatyti naujajame EJB QL. Hibernate siūlo duomenų paieškos ir atnaujinimo, jungčių kaupimo, operacijų valdymo, deklaratyvaus subjekto santykių valdymo ir deklaratyvių bei programinių užklausų galimybes.

Paukščio skrydžio vaizdas

Siūlomos EJB 3.0 specifikacijos pakeitimus galima suskirstyti į dvi kategorijas:

  • Anotacijomis pagrįstas EJB programavimo modelis, Be EJB 2.1 modelio, apibrėžiančio programos elgseną naudojant diegimo aprašus ir kelias sąsajas.
  • Naujas subjekto pupelių patvarumo modelis. EJB QL taip pat labai pasikeitė.

Šie pasiūlymai taip pat turi keletą šalutinių poveikių, pavyzdžiui, naują kliento programavimo modelį, verslo sąsajų naudojimą ir subjekto pupelių gyvavimo ciklą. Atkreipkite dėmesį, kad EJB 2.1 programavimo modelis (su diegimo aprašais ir namų / nuotolinėmis sąsajomis) vis dar galioja. Naujas supaprastintas modelis ne visiškai pakeičia EJB 2.1 modelį.

EJB anotacijos

Vienas iš svarbių ekspertų grupės tikslų yra sumažinti artefaktų, kuriuos turi pateikti pupelių tiekėjas, skaičių. Grupė atliko gana tvarkingą darbą, kad pasiektų šį tikslą. EJB 3.0 pasaulyje visos verslo pupelės yra teisingos paprastus senus „Java“ objektus (POJO) su atitinkamomis anotacijomis. Anotacijos gali būti naudojamos pupelių verslo sąsajai, O / R susiejimo informacijai, išteklių nuorodoms ir beveik viskam, kas buvo apibrėžta naudojant diegimo aprašus ar sąsajas EJB 2.1, apibrėžti. Diegimo aprašų nebereikia; namų sąsaja dingo, ir nebūtinai turite įdiegti verslo sąsają (konteineris gali ją sugeneruoti).

Pvz., Jūs deklaruojate sesijos pupelę be pilietybės naudodami @Betalė anotacija „Java“ klasėje. Valstybinėms pupelėms @ Pašalinti ant tam tikro metodo pažymima anotacija, nurodanti, kad pupelių egzempliorius turėtų būti pašalintas baigus iškvietimą pažymėtu metodu.

Norėdami sumažinti informacijos, kurią turite nurodyti komponentui, kiekį, ekspertų grupė priėmė a konfigūracija pagal išimtį požiūris, ty jūs pateikiate intuityvius numatytuosius nustatymus visoms anotacijoms, kad būtų galima padaryti išvadą apie daugumą bendros informacijos.

Naujas atkaklumo modelis

Naujosios esybės pupelės taip pat yra tik POJO su keliomis anotacijomis ir nėra patvarios esybės pagal savo gimimą. Esybės egzempliorius tampa nuolatinis, kai jis yra susietas su „EntityManager“ ir tampa a atkaklumo kontekstas. Nuolatinis kontekstas yra laisvai sinonimas su operacijos kontekstu; griežtai tariant, jis netiesiogiai egzistuoja kartu su sandorio apimtimi.

Esybių santykiai taip pat apibrėžiami per anotacijas. Be to, O / R žemėlapiai taip pat atliekami per anotacijas ir teikiamos keleto duomenų bazei būdingų operacijų palaikymas. Naudodamiesi EJB 2.1, kūrėjai naudojo savo sukurtus modelius arba naudojo nepagrįstus metodus (pavyzdžiui, automatinių raktų generavimo strategijas).

Kasimasis giliai

Atėjo laikas susipažinti su ankstyvojo EJB 3.0 projekto pasiūlymų specifika. Pradėkime nuo visų keturių įmonių pupelių rūšių ir pereikime prie pasiūlymų, susijusių su bendru EJB programavimo modeliu.

Be pilietybės seansinės pupelės:

Bevardis seanso pupelis (SLSB), parašytas EJB 3.0 būdu, yra tik paprastas „Java“ failas su klasės lygio anotacija @Betalė. Pupelių klasė gali įgyvendinti javax.ejb.SessionBean sąsaja, bet neprivalo (ir paprastai nebus).

SLSB nebeturi namų sąsajos - iš tikrųjų to nereikia nė vienam EJB tipui. Pupelių klasė gali įdiegti verslo sąsają arba jos neįdiegti. Jei ji neįdiegs jokių verslo sąsajų, verslo sąsaja bus sukurta naudojant visus viešus metodus. Jei verslo sąsajoje turėtų būti rodomi tik tam tikri metodai, visus tuos metodus galima pažymėti @BusinessMethod anotacija. Pagal numatytuosius nustatymus visos sukurtos sąsajos yra vietinės, tačiau @Nuotolinis anotacija gali būti naudojama norint nurodyti, kad turėtų būti sukurta nuotolinė sąsaja.

Pakanka šių kelių kodo eilučių, kad apibrėžtumėte a Labas pasauli pupelė. Naudojant EJB 2.1, tam pačiam pupeliui būtų reikėję bent dviejų sąsajų, vienos įgyvendinimo klasės su keliais tuščiais metodų diegimais ir diegimo aprašo.

importuoti javax.ejb. *; / ** * Sesijos pupelė be pilietybės, reikalaujanti, kad jai būtų sukurta nuotolinio verslo * sąsaja. * / @Stateless @Remote public class HelloWorldBean {public String sayHello () {return "Sveikas pasaulis !!!"; }} 

Išsamų šaltinio kodą, kuris pridedamas prie šio straipsnio, ieškokite šaltiniuose.

Valstybinės sesijos pupelės

SLSB istorija su „stateful session pupelėmis“ (SFSB) yra beveik tokia pati, išskyrus keletą specifinių SFSB punktų:

  • SFSB turėtų turėti galimybę inicijuoti save (pateikiamas per ejbCreate () metodas EJB 2.1 ir ankstesnėse versijose). „EJB 3.0“ specifikacijoje siūloma, kad tokie inicializavimo metodai būtų pateikiami kaip pasirinktiniai metodai ir pateikiami per pupelių verslo sąsają. Dabar klientui tenka iškviesti tinkamus inicializavimo metodus prieš naudojant pupelę. Ekspertų grupė vis dar diskutuoja dėl būtinybės pateikti anotaciją, žyminčią konkretų inicijavimo metodą.
  • Pupelių tiekėjas gali pažymėti bet kurį SFSB metodą @Pašalinti anotacija, nurodanti, kad pupelių egzempliorius turi būti pašalintas iškvietus anotuotą metodą. Vėlgi, ekspertų grupė vis dar diskutuoja, ar reikia įrenginio, nurodančio, kad pupelių negalima pašalinti, jei metodas nevisiškai baigiamas.

Čia yra mano nuomonė dviem atvirais klausimais:

  • Ar turėtų būti inicializavimo metodo anotacija? Mano balsas yra „taip“, darant prielaidą, kad sudėtinis rodinys užtikrins, kad prieš pradedant taikyti bet kurį kitą verslo metodą, bus iškviestas bent vienas iš inicijavimo metodų. Tai ne tik apsaugo nuo atsitiktinių programavimo klaidų, bet ir leidžia konteineriui labiau pasitikėti pakartotiniu SFSB egzempliorių naudojimu. Aiškumo dėlei leiskite čia paminėti, kad ne paskirtas inicijavimas metodai (pvz., ejbCreate) yra svarstomi; ekspertų grupė tik svarsto galimybę anotacijos metodą turėti kaip inicializavimo metodą.
  • Ar turėtų būti konfigūruojama, kad nenormalus @ Pašalinti metodas nepašalina pupelių egzemplioriaus? Vėlgi, mano balsas yra „taip“. Tai tik leis geriau kontroliuoti pupelių tiekėją ir klientų programuotojus. Lieka tik vienas klausimas: kas nutiks toms pupelėms, pažymėtoms kaip ne pašalintas nesėkmingai iškvietus šalinimo metodą, o konkretaus egzemplioriaus šalinimo metodas niekada nesibaigia sėkmingai? Negalite programiškai pašalinti tų egzempliorių, tačiau jie bus pašalinti pasibaigus sesijos laikui.

SFSB pavyzdį rasite šaltinio kode.

Pranešimais valdomos pupelės

Pranešimais pagrįstos pupelės (MDB) yra vienintelė pupelių rūšis, kuri turi įdiegti verslo sąsają. Šios sąsajos tipas nurodo pranešimų sistemos, kurią palaiko pupelė, tipą. JMS („Java Message Service“) pagrįstiems MDB ši sąsaja yra javax.jms.MessageListener. Atkreipkite dėmesį, kad MDB verslo sąsaja nėra iš tikrųjų verslo sąsaja, tai tik pranešimų sąsaja.

Subjektų pupelės

Subjektai pupelės pažymėtos @Entity anotacija ir visos objekto pupelių klasės ypatybės / laukai ne pažymėtas @Transient anotacija laikoma nuolatine. Nuolatiniai subjekto pupelių laukai yra eksponuojami per „JavaBean“ stiliaus ypatybes arba kaip viešieji / saugomi „Java“ klasės laukai.

Subjektų pupelės gali naudoti pagalbininkų klases atvaizduodamos subjekto pupelių būseną, tačiau šių klasių egzemplioriai neturi nuolatinės tapatybės. Vietoj to, jų egzistavimas yra stipriai susietas su nuosavybės subjekto pupelių pavyzdžiu; šie objektai taip pat nėra dalijami tarp subjektų.

Keletas objektų pupelių pavyzdžių rasite šaltinio kode.

Subjektų santykiai

„EJB 3.0“ palaiko tiek vienakrypčius, tiek dvikryptius ryšius tarp esybės pupelių, kurie gali būti santykiai „vienas su vienu“, „vienas su daugeliu“, „daug vienas su vienu“ arba „daug prieš daug“. Tačiau dvi dvikrypčio ryšio pusės išskiriamos kaip turinti pusė ir atvirkštinė pusė. Turinti šalis yra atsakinga už santykių pokyčių skleidimą duomenų bazėje. Asociacijoms „daugeliui į daugelį“ turi būti aiškiai nurodyta turinti pusė. Tiesą sakant, tai yra kita pusė, kurią nurodo isVersas = tiesa anotacijos narys kitoje pusėje ManyToMany anotacija; iš to išvesta turinti pusė. Ar ekspertų grupė nesakė, kad tai palengvina EJB?

O / R žemėlapiai

O / R atvaizdavimo modelis taip pat gerokai pasikeitė, palyginti su abstrakčiu atkaklumu ir schemomis grindžiamu požiūriu į Hibernate įkvėptą. Nors ekspertų grupė vis dar diskutuoja apie modelį ir aiškus vaizdas susidarys tik su kitu projektu, šiame projekte pateikiami aiškūs bendro požiūrio požymiai.

Vienam O / R atvaizdavimas bus nurodytas pačioje subjekto pupelių klasėje anotacijomis. Be to, reikia nurodyti konkrečias lenteles ir stulpelius, o ne abstrakčią patvarumo schemą. O / R atvaizdavimo modelis iš esmės palaiko savąją SQL; tai yra palaikymas gilesniu lygiu, ne tik galimybė vykdyti natūralias SQL užklausas. Pvz., Stulpelių apibrėžimų anotacija (@Kolonas) turi narį stulpelis Apibrėžimas tai gali būti kažkas panašaus columnDefinition = "BLOB NOT NULL".

Kliento programavimo modelis

EJB klientas gali gauti nuorodą į pupelių verslo sąsają naudodamas injekcijos mechanizmą (@ Suleiskite anotacija). Naudojant naujai pristatytą @ javax.ejb.EJBContext.lookup () metodas yra kitas požiūris. Tačiau specifikacija nėra aiški, kaip atskiras „Java“ klientas įgauna nuorodą į pupelių egzempliorių, nes atskiri „Java“ klientai veikia J2EE kliento talpykloje ir neturi prieigos prie @ javax.ejb.EJBContext objektas. Yra dar vienas mechanizmas - naujai pristatytas universaliojo konteksto objektas: @ javax.ejb. Kontekstas (). Bet vėlgi, specifikacijoje nėra pasakyta, kaip šį objektą galima naudoti kliento sudėtiniame rodinyje.

EJB QL

Užklausas galima apibrėžti per @PavadintaKlausimas anotacija. Du šios anotacijos nariai yra vardas ir queryString. Apibrėžus šią užklausą galima pasiekti naudojant EntityManager.createNamedQuery (vardas) metodas. Taip pat skambindami galite sukurti įprastą JDBC stiliaus („Java Database Connectivity“) užklausą EntityManager.createQuery (ejbqlString) arba savoji užklausa naudojant EntityManager.createNativeQuery (nativeSqlString).

EJB QL užklausose gali būti tiek poziciniai, tiek įvardyti parametrai. javax.ejb.Klausimas sąsajoje pateikiami šių parametrų nustatymo, naujinimų vykdymo, rezultatų įtraukimo ir kt. metodai.

Štai vienas pavyzdys, kaip galima sukurti ir vykdyti EJB QL užklausą:

.. .. @NamedQuery (name = "findAllCustomersWithName", queryString = "PASIRINKTI C IŠ Kliento c WHERE c.name LIKE: custName") .. .. @Inject public EntityManager em; klientai = em.createNamedQuery ("findAllCustomersWithName") .setParameter ("custName", "Smith") .listResults (); 

Toliau pateikiami keli iš patobulintų QL patobulinimų:

$config[zx-auto] not found$config[zx-overlay] not found