Il CDI ha senso se non esiste un livello Web e quindi nessuna sessione HTTP?

Question

Il nuovo JSR 299 "Contesti e Dipendenza dell'iniezione per Java EE" sembra essere basato sul concetto di "Ambito".

I bean vengono creati e associati a uno degli ambiti supportati: Applicazione, Sessione (mappata a una sessione HTTP), Conversazione e Richiesta.

Ha senso utilizzare CDI se non esiste alcuna sessione HTTP (ad esempio un'applicazione Enterprise che espone funzionalità tramite remote EJB) poiché i bean gestiti non verranno associati a nessun contesto (poiché non esistono)?

È persino possibile utilizzare CDI in uno scenario del genere? Quali vantaggi potrebbe comportare?

Answer 1

Mi ricorda la mia domanda che ho fatto qualche tempo fa: How does @SessionScoped work with EJB? Is CDI only for web-tier?

Sembra che l'idea di 'scope' è rilevante solo nel caso di HTTP Session.
Tuttavia, è possibile vedere un utilizzo valido dell'ambito @ApplicationScoped come metodo per implementare un bean singleton dell'applicazione, nonostante la richiesta sia HTTP.

Javadoc dice:

L'ambito di applicazione è attiva:

(...)

• nel corso di un servizio web Java EE invocazione,

• durante qualsiasi invocazione del metodo remoto di qualsiasi EJB, durante qualsiasi chiamata al metodo asincrono di qualsiasi EJB, durante qualsiasi chiamata a un EJB metodo timeout e durante la consegna dei messaggi a qualsiasi bean message-driven fagioli,

Answer 2

È inoltre possibile creare i propri ambiti. Il CDI è molto estensibile e può essere utilizzato in una varietà di situazioni. Viene anche utilizzato in applicazioni SE in cui non esiste né HttpSession né HttpRequest.

Answer 3

Oltre a ciò, CDI non è solo per la gestione del ciclo di vita, è possibile utilizzarlo per fare l'iniezione delle dipendenze separando così le interfacce dalle loro implementazioni in modo molto pulito. Puoi anche eseguire alcune tecniche AOP utilizzando interceptor e decoratori o creare un pattern Observer molto loose-coupled sfruttando gli eventi CDI.