Linea guida: Identificazione di bean di entità
Questa linea guida descrive come identificare e modellare i bean di entità relativi ad un'applicazione J2EE.
Relazioni
Descrizione principale

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à.