Quando è necessario o conveniente utilizzare Spring o EJB3 o tutti insieme?

Sono un po ‘confuso dall’uso misto di JSF2 + Spring + EJB3 o di qualsiasi combinazione di questi. So che una delle caratteristiche principali di Spring è l’iniezione delle dipendenze, ma con i fagioli gestiti da JSF posso usare le ano @ManagedBean e @ManagedProperty e ottengo la funzionalità di iniezione di dipendenza. Con EJB3 sono ancora più confuso su quando usarlo insieme a JSF o se c’è anche un motivo per usarlo.

Quindi, in che tipo di situazione sarebbe una buona idea usare Spring + JSF2 o EJB3 + JSF2?

Fino ad ora ho creato solo alcune piccole applicazioni web usando solo JSF2 e non avevo mai avuto bisogno di usare Spring o EJB3. Tuttavia, sto vedendo in molti posti che le persone stanno lavorando con tutte queste cose insieme.

Prima di tutto, Spring e EJB (+ JTA) sono tecnologie concorrenti e di solito non devono essere usate insieme nella stessa applicazione. Scegli l’uno o l’altro. Spring o EJB (+ JTA). Non ti dirò quale scegliere, ti dirò solo un po ‘di storia e fatti in modo che tu possa prendere più facilmente la decisione.


Il problema principale che stanno cercando di risolvere è fornire un’API a livello di servizio business con gestione automatica delle transazioni. Immagina di dover triggersre più query SQL per eseguire una singola attività di business (ad esempio, effettuare un ordine), e una di esse non è riuscita, quindi ovviamente vorrai che tutto venga ripristinato, in modo che il DB sia mantenuto nello stesso stato come era prima, come se non fosse successo nulla. Se non hai fatto uso di transazioni, il DB verrebbe lasciato in uno stato non valido perché il primo gruppo di query è effettivamente riuscito.

Se hai familiarità con il JDBC di base, dovresti sapere che questo può essere ottenuto distriggersndo l’autocommit sulla connessione, quindi triggersndo quelle query in sequenza, quindi eseguendo commit() nello stesso try nel cui catch (SQLException) a rollback() viene eseguito. Questo è tuttavia abbastanza noioso da implementare ogni volta.

Con Spring ed EJB (+ JTA), una singola chiamata al metodo di servizio aziendale (senza stato) conta per impostazione predefinita in modo trasparente come un’unica transazione completa. In questo modo non è necessario preoccuparsi della gestione delle transazioni. Non è necessario creare manualmente EntityManagerFactory , né chiamare esplicitamente em.getTransaction().begin() e ciò che si farebbe quando si accoppiano strettamente la logica del servizio di business in una class di bean di supporto JSF e / o si utilizza RESOURCE_LOCAL invece di JTA in JPA. Ad esempio, potresti avere solo la seguente class EJB che utilizza JPA:

 @Stateless public class OrderService { @PersistenceContext private EntityManager em; @EJB private ProductService productService; public void placeOrder(Order newOrder) { for (Product orderedproduct : newOrder.getProducts()) { productService.updateQuantity(orderedproduct); } em.persist(newOrder); } } 

Se hai un @EJB private OrderService orderService; nel bean di supporto JSF e invocare orderService.placeOrder(newOrder); nel metodo action, verrà eseguita una singola transazione completa. Se, per esempio, una delle chiamate updateQuantity() o la chiamata persist() falliscono con un’eccezione, allora eseguirà il rollback di tutte le chiamate updateQuantity() eseguite finora e lascerà il DB in uno stato pulito e nitido. Ovviamente, è ansible rilevare tale eccezione nel bean di supporto JSF e visualizzare un messaggio di volti.

Si noti che “Spring” è una struttura piuttosto ampia che non solo compete con EJB, ma anche con CDI e JPA. Precedentemente, durante l’oscurità J2EE, quando EJB 2.x era estremamente terribile da implementare (l’esempio di EJB 3.x OrderService sopra OrderService in EJB 2.x richiede almeno 5 volte più codice e qualche codice XML). Spring offrì un’alternativa molto migliore che richiedeva meno codice Java (ma ancora molti codici XML). J2EE / EJB2 hanno imparato le lezioni da Spring e sono giunti con Java EE 5, che offre una nuova API EJB3 che è ancora più liscia di Spring e non ha richiesto alcun codice XML.

Spring offre anche IoC / DI (inversione del controllo, iniezione di dipendenza) fuori dagli schemi. Questo è stato durante l’era J2EE configurata da XML che può andare abbastanza fuori bordo. Oggi Spring usa anche le annotazioni, ma è ancora necessario un po ‘di XML. A partire da Java EE 6, dopo aver appreso le lezioni di Spring, CDI viene offerto con la stessa funzionalità DI, ma senza bisogno di XML. Con Spring DI @Component / @Autowired e CDI @Named / @Inject puoi ottenere lo stesso risultato di JSF con @ManagedBean / @ManagedProperty , ma Spring DI e CDI offre molti più vantaggi attorno ad esso: puoi ad esempio scrivere interceptor a pre – creazione o distruzione di un bean gestito o post-processo gestito o una chiamata al metodo bean gestito, è ansible creare ambiti personalizzati, produttori e consumatori, è ansible iniettare un’istanza di ambito più ristretto in un’istanza di ambito più ampio, ecc.

Spring offre anche MVC che essenzialmente compete a JSF. Non ha senso combinare JSF con Spring MVC. Ulteriori Spring offre anche Data, che è essenzialmente un ulteriore livello di astrazione su JPA, che riduce ulteriormente la dimensione di DAO (ma che in sostanza non rappresenta il livello del servizio aziendale nel suo complesso).

Guarda anche:

  • Che cosa è esattamente Java EE?
  • Controller JSF, servizio e DAO
  • Fagioli @Stateless contro fagioli @Stateful

Non c’è una vera risposta facile qui in quanto la spring è molte cose.

A un livello molto alto, Spring compete con Java EE, il che significa che si utilizzerà uno di questi come un framework stack completo.

A un livello più fine, il contenitore Spring IoC e Spring Beans competono con la combinazione di CDI ed EJB in Java EE.

Per quanto riguarda il livello web, Spring MVC compete con JSF. Alcuni Spring xyzTemplate compete con le interfacce JPA (entrambi possono utilizzare ad esempio Hibernate come implementazione di quelli).

È ansible combinare e abbinare; Ad esempio, utilizzare CDI e bean EJB con Spring MVC, OPPURE utilizzare Spring Beans con JSF.

Normalmente non utilizzerai 2 tecnici in competizione diretta insieme. Spring bean + CDI + EJB nella stessa app, o Spring MVC + JSF è stupido.