Quanti EJB sono troppi?

Question

Attualmente sto sviluppando un grosso pezzo di base software su JavaEE. Abbiamo seguito le linee guida generali di JavaEE che affermano che ogni serie correlata di operazioni dovrebbe essere inserita nel proprio bean. Al momento abbiamo oltre 275 classi EJB diverse (fagioli Session stateless). È probabile che questo numero aumenterà almeno il doppio di quel numero.

Mi piacerebbe sapere se i contenitori EJB sono progettati per contenere molti tipi diversi di EJB. Sono interessato a sapere se stiamo per ottenere penalità da prestazioni inadeguate dall'avere troppe classi di questo tipo e se alcuni tweaking a livello di application server possono aiutare ad alleviare questi problemi ipotetici.

Usiamo Glassfish v2 con JavaEE 5 su Java 6 di Sun, quindi i consigli su questa particolare piattaforma sarebbero molto apprezzati.

Answer 1

Gli EJB devono essere a grana fine, quindi non vi è alcun problema con ciò che si sta facendo se si è coerenti nel progetto.

Gli EJB sono solo classi, quindi non c'è nulla di cui preoccuparsi tranne che per il carico generale, che è ortogonale al numero di EJB che avete distribuito.

Se si è preoccupati per le prestazioni, inserire alcune metriche di monitoraggio o di altre prestazioni e vedere come vanno le cose mentre si aggiungono nuove funzionalità.

Alla fine della giornata, preferiresti mantenere meno classi con molti metodi o molte classi con meno metodi? So quale scegliere.

Answer 2

(C'è un modo per dire "non del tutto", senza essere bocciata?)

Su una nota seria, utilizzare come molti come avete bisogno. La mia regola generale è (sia per gli EJB che per le classi in generale) se non riesci a descrivere completamente cosa fa la cosa in un nome di classe di circa tre parole, hai fatto troppo.

Per quanto riguarda le prestazioni, ho il sospetto che se il sistema inizia a soffrire di "troppi EJB" hai problemi molto più grandi da qualche parte.

Answer 3

Gli EJB sono componenti e non classi e si dovrebbe pensare a loro in quel termine ed esprimere adeguatamente la progettazione del sistema.

La granularità del componente è ovviamente dipendente dal dominio.

Supponiamo che stiate modellando un (abbastanza vecchio stile) computer con EJB. Resistori, transistor, bobine, ecc .: questi sono pojos. Chip e schede sono componenti. L'assemblea è l'EAR.

La granularità dell'interfaccia deve riflettere la funzione del componente.

Answer 4

EJB non è solo un'istanza di classe normale. Ha bisogno di manutenzione extra in container, pool di istanze, ecc. Un sacco di EJB richiede molte risorse nel server.

Non penso che un sistema abbia bisogno di centinaia di EJB. Mentre ero coinvolto anche in un'applicazione con 90 EJB, era un incubo: < Non c'era testabilità e la distribuzione è anche un compito enorme.