Entity bean

A HupWiki-ből...

Az Enterprise Bean-ek háromfélék lehetnek:

• session bean
• entity bean
• message-driven bean

Egy többrétegû alkalmazásnak két vége van; a klienseket a session bean-ek képviselik. Az entity bean-ek az alkalmazás másik végén található objektumokat képviselik, amelyek valamilyen perzisztens tárolóból származnak (tipikus példa: egy relációs adatbázisból). Egy entity bean többnyire megfeleltethető egy táblának az adatbázisban, és minden egyes példánya a tábla egy sorát reprezentálja.

- Ezt a bekezdést légy szíves javítsd ki, lásd a Session bean-ek címszóhoz írtakat is. A Session bean-ek tipikusan nem kliens szerepet játszanak, mivel a többrétegű alkalmazás fejlesztésben nem az adatbázis A szerver, hanem az csak egy adattároló. A szerver terület, ha már mindenáron kliens-szerver osztályozást akarsz használni, magában foglalja az üzleti logika szerver oldali részét is, amit tipikusan Session bean-ekben szoktak elhelyezni.

Az entity bean-ek jelentősen eltérnek a session bean-ektől:

• Szerver leállást túlélő perzisztens állapottal rendelkeznek
• Állapotuk mentését illetve visszaállítását saját maguk is végezhetik (Bean Managed Persistence)
• De a már említett szabványos környezet (a Bean Container) is biztosít hozzá támogatást (Container Managed Persistence)
• Több kliens megosztva használhatja őket (de csak atomikusan, tehát egyszerre egy szál)
• Emiatt szükséges, hogy entity bean-ek résztvételével tranzakciók is lebonyolíthatóak legyenek, a Bean Container ezt is támogatja (ez a Session bean-ekre ugyanúgy igaz).
• Az entity bean-ek rendelkeznek egyedi azonosítóval, egy elsődleges kulccsal, ami alapján kereshető (a Home interfészen található findByPrimaryKey metódus segítségével)
• Entity bean-ek között értelmezhetők relációk. Ez saját perzisztencia-kezelés esetén úgy működik, ahogy megírjuk, a környezet által kezelt esetben ,,container-managed relationship"-ről szokás beszélni, és a relációs adatbázisok szerkesztésénél megszokothoz hasonló módon hozhatjuk létre őket
• Lehetséges rajtuk kereséseket futtatni, vagy finder metódusokkal, vagy dinamikus EJB-QL query-k segítségével segítségével

Amikor entity bean-t érdemes használni:

• ha egy Bean kevésbé eljárást, inkább valamely üzleti objektumot képvisel
• ha egy Bean állapotának meg kell őrződnie
• ha egy olyan központi szinkronizációs pontra van szükség, amely újraindítások közt is garantáltan megörződik