Che uso fanno gli EJB

Attualmente sto imparando Jave-EE, avendo un sacco di esperienza C ++ e avendo imparato Java SE. Non capisco lo scopo di Enterprise Java Beans; Qualcuno può chiarire questo per me. Non sono interessato agli usi legacy : questo è nel contesto di EJB-3.1 e Java-EE 6.

Sembra che alcune persone li usino per contenere la logica di business, per implementare il livello aziendale dell’architettura convenzionale a 3 livelli. Questo separa la logica del dominio dagli oggetti del dominio, portando a un modello di dominio anemico . Ma questo va contro tutti i miei istinti di OOD; Sono d’accordo con Martin Fowler sul fatto che sia un anti-modello . Devo rilassare le mie obiezioni a un modello di dominio anemico? O i bean hanno altri usi?

L’uso di Java EE non implica automaticamente un modello di dominio anemico, così come è ansible scrivere codice in java, ciò che non fa buon uso delle best practice non significa che non sia ansible in java. Credo che il punto di Martin Fowler fosse J2EE (si noti l’uso di J2EE e non di Java EE) piuttosto un funzionamento forzato di logica e dati. L’utilizzo di entity framework basate su POJO consente a dati e comportamenti di modellarsi in modo appropriato. La “logica di business” nei tuoi EJB di solito orchestra l’applicazione della logica di business, ma il più delle volte non la esegue, di solito è un involucro molto sottile.

Gli EJB formano quindi la tua API di servizio, hai bisogno di questa piattaforma / framework che stai utilizzando, devi avere qualcosa che puoi invocare fisicamente, è un punto di ingresso. Che si stia implementando utilizzando Spring, servizi Web, ecc. È necessario un livello di servizio, non c’è nulla che impedisca l’implementazione in Java EE. Un esempio piuttosto forzato

@Stateless public SomeServiceImpl implements SomeService someServiceMethod() { delegate.doSomething(); } } public SomeServiceDelegate implements SomeService someServiceMethod() { modelObject.doSomething(); } } 

Non voglio addentrarmi nei motivi per preferire gli EJB rispetto a qualsiasi altra tecnologia, ma voglio solo sottolineare che utilizzarli non significa che la tua implementazione non possa utilizzare le migliori pratiche.

Come indicato da diverse altre risposte, gli EJB sono perfetti per implementare il livello di servizio. Sono un tipo di bean molto moderno e leggero in Java EE. Nonostante il nome non è ansible confrontarli con le bestie EJB2 pesanti draconiane che erano in J2EE. Tutti sono d’accordo che quelli sono stati un disastro, ma non è più il 2002.

Da quando EJB3 (2006), i bean EJB sono stati una tecnologia perfetta.

Aiutano molto qui fornendo transazioni dichiarative (ogni metodo di inserimento avvia automaticamente una transazione se non ne è già in corso una, anche se può essere modificata se lo si desidera), il pooling, la sicurezza, il locking, il remoting e alcuni. Vedere le seguenti risposte per alcuni dettagli aggiuntivi:

  • Framework per la stratificazione di architetture riutilizzabili
  • In quali situazioni vengono utilizzati i bean? Sono richiesti nei siti web / sviluppo di applicazioni web?
  • EJB 3 o Hibernate 3
  • @EJB iniezione vs ricerca – problema di prestazioni

Le transazioni sono state spiegate qui, ma per aggiungere a questo: non è qualcosa che è necessario solo per sistemi altamente complessi e altamente sicuri. Direi che è un requisito fondamentale anche quando si tratta solo di database. Se elaboro un semplice ordine, desidero che l’inventario e l’ordine siano entrambi aggiornati o entrambi non lo siano affatto. Questo è fondamentale come avere PK e FK nel database per garantire l’integrità.

I bean rendono banale la gestione delle transazioni. Senza EJB c’è molto codice per l’avvio, l’invio o il rollback del tx.

Inoltre, non bisogna sottovalutare i vantaggi del pooling e degli stub forniti da EJB. Significa che un bean può avere un sacco di EJB iniettati, e non devi preoccuparti che vengano istanziati ogni volta che viene creato un bean. In caso contrario, ciò sarebbe particolarmente problematico quando non tutti gli EJB sarebbero utilizzati ogni volta.

A causa del pooling, tuttavia, vengono iniettati solo stub molto leggeri, che sono più simili a un tipo di URL che puntano a un’istanza reale. Questi costi quasi nulla in termini di memoria o sovraccarico della CPU da iniettare.

Gli EJB dispongono anche di annotazioni per dichiarare che sono Singletons, organizzano il loro comportamento di blocco (write locks / read locks), dichiarando che uno dovrebbe essere avviato all’avvio, consentire loro di gestire un cosiddetto contesto di persistenza esteso (un contesto di persistenza non impostato su un TX ), eccetera.

Queste sono tutte preoccupazioni che non vuoi nelle tue quadro snelle . In molte architetture, un object Utente, per esempio, è una semplice quadro di dati che voglio inviare attraverso i livelli. Non voglio che la mia istanza utente abbia un metodo sendMsg () e abbia una risorsa JMS come dipendenza, in modo che l’invio di messaggi possa essere eseguito improvvisamente da qualche client. Non sono proprio sicuro del motivo per cui la gente pensa che sia in qualche modo “naturale” e “OOP”.

Nel mondo reale, inoltre, non invoco un’operazione sendMsg sul mio amico Joe ogni volta che voglio mandargli una cartolina. Invece, indirizzo una scheda e la porto alla centrale o la metto in una buca delle lettere.

Inoltre, non invoco un’operazione bake () su una torta. Invece, ho messo la torta in un forno, ecc.

Citi già il caso d’uso “implementa la logica aziendale”.

EJB – in EJB 3.x Session Beans, Message Driven Beans e in 3.1 i nuovi Singleton Beans consentono infatti di implementare la logica biz. Session Beans spesso server come Facade a cui i client si connettono. Questi client possono essere servlet per servire i contenuti tramite ad esempio HTTP o anche client “grassi” che comunicano su altri (più binari) protocolli agli EJB.

I bean Driven di messaggi fungono da endpoint di comunicazioni asincrone e possono essi stessi chiamare metodi su Session Beans come esempio.

Tutti gli EJB hanno una cosa in comune, il che li rende molto attraenti: sono gestiti da un contenitore. Quindi il contenitore si occupa di istanziazione, raggruppamento, transazioni, sicurezza ecc.

Se scrivi in ​​un EJB

 @Resource DataSource x; 

Il contenitore si assicura che quando il bean è pronto a ricevere chiamate di metodo, la variabile ‘x’ contenga un’origine dati adatta.

Il raggruppamento di bean consente di avere molti più client che si collegano a un sito di quanto non si possa fare a meno, in quanto le istanze sono condivise (Stateless SB) o le istanze possono essere sostituite dal contenitore nell’archivio secondario se la memoria è stretta e -triggersli più tardi

In EJB 3, i vecchi EntityBeans di EJB 1.xe 2.x sono andati e sostituiti da JPA, che crea il modello di dati di dominio dei POJO, che può essere annotato per fornire la semantica relazionale o la semantica può essere fornita da esterni File XML

Con JPA (che non richiede affatto EJB), i bean servono spesso a implementare la gestione di tali quadro:

 @Stateless public class MyBean { @PersistenceContext EntityManager em; public Foo getFoo(String name) { Query q = em.createQuery("SELECT f FROM Foo f WHERE f.name = :name"); q.setParameter("name",name); return q.getSingleValue(); } } 

Un paio di punti:

  • I bean non esistono da soli; vivono in un contenitore EJB, che offre alcuni servizi molto utili attraverso di essi, come la sicurezza dichiarativa, le transazioni dichiarative e il clustering relativamente facile.
  • Mentre è vero che i modelli di dominio anemici sono un antipattern: una volta che la logica aziendale diventa più complessa, ad esempio quando più applicazioni operano sullo stesso modello, separare la maggior parte della logica dal modello diventa una questione di separazione delle preoccupazioni.

Solo un commento dall’esperienza personale …

Non dubito dei vantaggi degli EJB, ma avendo lavorato con loro, vedo che gli EJB si adattano solo nei casi in cui la sicurezza e le transazioni sono molto importanti (ad esempio: applicazioni finanziarie). Per il 90% dei casi staresti bene senza EJB. Un’altra cosa … la scalabilità e gli EJB non sono buoni amici.

Alcuni ragazzi dicono in discussione in questo modo che l’EJB diventa utile in EJB3 non prima, e questo non è sicuro. è diventato più potente specialmente con l’JPA, ma EJB1.0 e EJB2.1 hanno fatto ancora molto. forse non l’hanno usato in grandi applicazioni, così dicono.

ad esempio POJO non può gestire una Transazione, quindi in EJB puoi specificare il tipo di transazione per un metodo specifico è che richiede una nuova transazione o non dalla transazione.

nella mia organizzazione abbiamo ERP compilato ex novo e utilizziamo il bean nella business logic, era del 2000 e il bean era la versione 1.0. e non solo separa il livello aziendale dagli altri tre, ma separa anche il sistema gli uni dagli altri, ad esempio: il modulo finanziario è separato dal modulo HR. e se vogliono aggiungere un nuovo modulo possono aggiungerlo senza riavviare il sistema e si integrerà perfettamente con il sistema.

e ricordalo nell’EJB: ciò che vedi nel codice non è nulla e ciò che il contenitore EJB sta facendo per te è tutto :).

stateful-enterprise-java-fagioli apolidi-e-

ejb-stateless-session-fagioli-e-stateful-session-bean