Introduzione
Questa linea guida si focalizza sull'identificazione di bean di entità. Un'ulteriore guida ai bean di entità viene
fornita dalla Linea
guida: Bean di entità, mentre una guida generale agli EJB si trova nella Linea guida: EJB (Enterprise JavaBean)
Identificazione di bean di entità
Le classi di analisi dell'entità (vedere Prodotto di lavoro: Classe di analisi) sono spesso buone candidate ai
bean di entità, poiché questi ultimi sono predisposti ai dati permanenti. I bean di entità corrispondono ad entità
business che contengono uno stato permanente. Forniscono servizi che implementano la logica specifica all'entità
business. Un'altra caratteristica dei bean di entità consiste nella capacità di fornire servizi a molti client
simultaneamente. Il contenitore EJB gestisce il coordinamento di questi client e delle loro transazioni.
I bean di entità sono principalmente utilizzati per la persistenza ma possono anche contenere la logica di business.
Generalmente, un bean di entità dovrebbe contenere soltanto una logica di business inerente ai dati resi permanenti dai
bean di entità e ad oggetti dei dati dipendenti. La logica dei bean inter-entità dovrebbe essere inserita in bean di
sessione per minimizzare l'accoppiamento tra bean di entità.
Modellazione di bean di entità
Vedere la Linea guida: Identificazione di EJB (Enterprise JavaBean).
Granularità
La granularità si riferisce alla dimensione dei dati rappresentati da EJB di entità. La granularità appropriata può
dipendere dalla versione della specifica EJB impiegata.
Prima ancora di EJB 2.0, gli EJB di entità erano raccomandati per la grande granularità - poiché si trattava
solitamente di ampi raggruppamenti di dati presi da diverse tabelle di database. Questo perché ogni EJB di entità
comportava spese considerevoli - specialmente se asportabile. Ad esempio, le voci di riga di un'unità o le celle di un
foglio elettronico sono troppo dettagliate e spesso non accessibili in una rete. Al contrario, i raggruppamenti logici
delle voci di un'unità o un sottoinsieme di celle di un foglio elettronico possono essere modellati come EJB di entità
se si richiede un'ulteriore logica di business relativa ai dati.
EJB 2.0 è in un certo senso diverso - l'introduzione di interfacce locali riduce alcuni costi e consente di modellare
oggetti più dettagliati come EJB. Le interfacce locali e remote sono descritte nel Concetto: Panoramica di J2EE (Java 2 Platform Enterprise Edition). Un'interfaccia
locale non comporta spese relative a un'interfaccia remota e facilita dunque l'interazione tra bean strettamente
associati. Le interfacce locali sono particolarmente utili ad entità più dettagliate utilizzate per formare un'entità
più ampia, responsabile della creazione e della distruzione dei componenti. I client usano l'interfaccia remota
dell'entità più ampia che, a sua volta, utilizza le interfacce locali per interagire con i suoi componenti.
Tuttavia, se un bean di entità ha una relazione di composizione con un'altra classe, è possibile modellare quest'ultima
come une classe Java ordinaria anziché come un bean di entità. Se si utilizza una permanenza gestita dal contenitore,
questa classe Java sarà indicata come "classe di valore dipendente". Le classi di valore dipendenti sono più semplici e
veloci da sviluppare e da testare dei bean di entità e rappresentano una buona opzione, considerato che la classe
composta non richiede caratteristiche di bean di entità. Alcuni limiti delle classi di valore dipendenti derivano dal
fatto che:
-
non possono contenere riferimenti di bean di entità
-
sono "ottenute" e "impostate" dal valore, che ha un suo costo di prestazione ma facilita l'accesso da interfacce
remote
Incapsulamento
Includiamo una serie di bean di entità correlati in una facade di bean di sessione per fornire un'interfaccia logica
relativa alla manipolazione delle entità business che corrispondono agli EJB di entità. Vedere la Linea guida: Identificazione di bean di sessione.
Un approccio simile può essere adottato da un bean di entità per incapsulare una serie di altri bean di entità locali,
di solito dipendenti. I client remoti accedono a tutti i dati attraverso il bean di entità "principale". Core J2EE
Patterns - Composite Entity Pattern [ALU01] descrive questa alternativa - tuttavia, raccomanda la facade di bean di
sessione come metodo più semplice per gestire relazioni di bean di entità.
|