Backing beans (@ManagedBean) o CDI Beans (@Named)?

Ho appena iniziato a leggere attraverso Core JavaServer Faces, 3rd Ed. e dicono questo (sottolineatura mia):

È un incidente storico che ci siano due meccanismi separati, fagioli CDI e fagioli gestiti JSF, per i bean che possono essere usati nelle pagine JSF. Ti consigliamo di utilizzare i bean CDI a meno che la tua applicazione non lavori su un servlet runner semplice come Tomcat.

Perché? Non forniscono alcuna giustificazione. Ho utilizzato @ManagedBean per tutti i bean in un’applicazione prototipo in esecuzione su GlassFish 3 e non ho notato alcun problema con questo. Non mi interessa particolarmente la migrazione da @ManagedBean a @Named , ma voglio sapere perché dovrei preoccuparmi .

Il CDI è preferito rispetto al semplice JSF perché CDI consente l’iniezione delle dipendenze a livello di JavaEE. Puoi anche iniettare POJO e lasciarli gestire. Con JSF puoi solo inserire un sottoinsieme di ciò che puoi con CDI.

Usa CDI.

Come da JSF 2.3, @ManagedBean è deprecato . Vedi anche la specifica numero 1417 . Ciò significa che non esiste più un motivo per scegliere @ManagedBean su @Named . Questo è stato implementato per la prima volta nella versione beta di Mojarra 2.3.0 m06.

inserisci la descrizione dell'immagine qui


Storia

La differenza principale è che @ManagedBean è gestito da framework JSF ed è accessibile solo tramite @ManagedProperty a un altro bean gestito JSF. @Named è gestito dal server delle applicazioni (il contenitore) tramite framework CDI ed è disponibile tramite @Inject per qualsiasi tipo di object gestito dal contenitore come @WebListener , @WebFilter , @WebServlet , @Path , @Stateless , ecc. E persino un JSF @ManagedBean . Dall’altro lato, @ManagedProperty non funziona all’interno di @Named o di qualsiasi altro artefatto gestito dal contenitore. Funziona davvero solo in @ManagedBean .

Un’altra differenza è che CDI in effetti inietta i delegati che delegano all’istanza corrente nello scope di destinazione su una base per ogni richiesta / thread (come come se gli EJB siano stati iniettati). Questo meccanismo consente di iniettare un bean con un ambito più ristretto in un bean con un ambito più ampio, che non è ansible con JSF @ManagedProperty . JSF “inietta” qui l’istanza fisica direttamente invocando un setter (che è anche esattamente il motivo per cui un setter è richiesto, mentre non è richiesto con @Inject ).

Anche se non direttamente uno svantaggio – ci sono altri modi – l’ambito di @ManagedBean è semplicemente limitato. Dall’altra prospettiva, se non vuoi esporre “troppo” per @Inject , puoi anche solo mantenere i bean gestiti @ManagedBean . È come protected contro public . Ma questo non conta davvero.

Almeno, in JSF 2.0 / 2.1, il principale svantaggio della gestione dei @ViewScoped di @ViewScoped@ViewScoped JSF da parte di CDI è che non esiste un equivalente CDI di @ViewScoped . @ConversationScoped si avvicina, ma richiede comunque l’avvio e l’arresto manuale e aggiunge un brutto parametro di richiesta cid agli URL di risultato. MyFaces CODI semplifica il bridging in modo completamente trasparente di javax.faces.bean.ViewScoped di JSF su CDI, quindi puoi semplicemente fare @Named @ViewScoped , tuttavia aggiunge un brutto windowId parametro di richiesta agli URL di risultato, anche su plain vanilla page-to-page navigazione. OmniFaces risolve tutto ciò con un vero CDI @ViewScoped che lega realmente l’ambito del bean allo stato di visualizzazione JSF anziché a un parametro di richiesta arbitrario.

JSF 2.2 (che è stato rilasciato 3 anni dopo questa domanda / risposta) offre una nuova annotazione completamente compatibile con CDI @ViewScoped disponibile in javax.faces.view.ViewScoped . JSF 2.2 arriva anche con un CDI-only @FlowScoped che non ha un equivalente @ManagedBean , con cui spinge gli utenti JSF verso CDI. L’aspettativa è che @ManagedBean e gli amici siano deprecati come da Java EE 8. Se attualmente stai ancora utilizzando @ManagedBean , è quindi vivamente consigliabile passare a CDI per essere preparati per futuri percorsi di aggiornamento. CDI è facilmente disponibile in contenitori compatibili con Java Web EE Profile, come WildFly, TomEE e GlassFish. Per Tomcat, devi installarlo separatamente, esattamente come hai fatto per JSF. Vedi anche Come installare CDI in Tomcat?

Con Java EE 6 e CDI hai un’opzione diversa per Managed Beans

  • @javax.faces.bean.ManagedBean fa riferimento a JSR 314 ed è stato introdotto con JSF 2.0. L’objective principale era evitare la configurazione nel file faces-config.xml per utilizzare il bean all’interno di una pagina JSF.
  • @javax.annotation.ManagedBean(“myBean”) è definito da JSR 316. Generalizza i bean gestiti JSF da utilizzare altrove in Java EE
  • @javax.inject.Named(“myBean”) sono quasi gli stessi, come sopra, eccetto che è necessario un file beans.xml nella cartella web / WEB-INF per triggersre CDI.

Stavo usando CDI in GlassFish 3.0.1, ma per farlo funzionare ho dovuto importare il framework Seam 3 (Weld). Ha funzionato abbastanza bene.

In GlassFish 3.1 CDI ha smesso di funzionare e Seam Weld ha smesso di funzionare con esso. Ho aperto un bug su questo ma non l’ho ancora visto risolto. Ho dovuto convertire tutto il mio codice in usando le annotazioni javax.faces. * Ma ho intenzione di tornare al CDI una volta che funzionano.

Sono d’accordo che dovresti usare CDI, ma un problema che non ho ancora visto risolto è cosa fare con l’annotazione @ViewScoped. Ho un sacco di codice che dipende da questo. Non è chiaro se @ViewScoped funzioni se non si sta usando @ManagedBean con esso. Se qualcuno può chiarirlo, lo apprezzerei.

Un buon motivo per passare a CDI: si potrebbe avere una risorsa con ambito sessione comune (profilo utente per esempio) @Inject ‘ed in entrambi i bean gestiti JSF e servizi REST (cioè, Jersey / JAX-RS).

D’altra parte, @ViewScoped è un @ViewScoped motivo per restare con JSF @ManagedBean , specialmente per qualsiasi cosa con AJAX significativo. Non esiste una sostituzione standard per questo in CDI.

Sembra che possa avere qualche supporto per @ViewScoped simile a @ViewScoped per i fagioli CDI, ma non l’ho mai giocato personalmente.

http://seamframework.org/Seam3/FacesModule