Sauvegarde de beans (@ManagedBean) ou de CDI Beans (@Named)?
Je viens de commencer à lire Core JavaServer Faces, 3e éd. et ils disent ceci (c'est moi qui souligne):
C'est un accident historique qu'il existe deux mécanismes distincts, les beans CDI et les beans gérés par JSF, pour les beans pouvant être utilisés dans des pages JSF. Nous vous suggérons d'utiliser des beans CDI sauf si votre application doit fonctionner sur un programme d'exécution de servlet tel que Tomcat.
Pourquoi? Ils ne fournissent aucune justification . J'ai utilisé @ManagedBean pour tous les haricots d’une application prototype exécutée sur GlassFish 3, et je n’ai pas vraiment remarqué de problème. Cela ne me dérange pas particulièrement de migrer de @ManagedBean à @Named, mais je veux savoir pourquoi je devrais me donner la peine .
CDI est préférable à JSF brut car CDI permet l’injection de dépendances à l’échelle de JavaEE. Vous pouvez également injecter des POJO et les gérer. Avec JSF, vous ne pouvez injecter qu'un sous-ensemble de ce que vous pouvez avec CDI.
Utilisez CDI.
Selon JSF 2.3, @ManagedBean Est obsolète. Voir aussi numéro de spécification 1417 . Cela signifie qu'il n'y a plus aucune raison de choisir @ManagedBean Sur @Named. Cela a été implémenté pour la première fois dans la version bêta de Mojarra 2.3.0 m06.
Histoire
La principale différence est que @ManagedBean est géré par le framework JSF et n’est disponible que via @ManagedProperty disponible pour un autre bean géré par JSF. @Named est géré par le serveur d'applications (le conteneur) via l'infrastructure CDI et via @Inject disponible pour tout type d'artefact géré par le conteneur comme @WebListener, @WebFilter, @WebServlet, @Path, @Stateless, etc. et même un JSF @ManagedBean. De l'autre côté, @ManagedProperty Fonctionne pas fonctionne à l'intérieur d'un @Named Ou de tout autre artefact géré par le conteneur. Cela ne fonctionne vraiment que dans @ManagedBean.
Une autre différence réside dans le fait que CDI injecte des proxies déléguant à l'instance actuelle dans l'étendue cible sur une base par requête/thread (par exemple, comment les EJB ont été injectés). Ce mécanisme permet d'injecter un haricot d'une portée plus étroite dans un haricot d'une portée plus large, ce qui n'est pas possible avec JSF @ManagedProperty. JSF "injecte" ici l'instance physique directement en invoquant un setter (c'est aussi pourquoi un setter est requis, alors que c'est pas requis avec @Inject).
Bien que ce ne soit pas directement un inconvénient - il existe d'autres moyens - la portée de @ManagedBean Est simplement limitée. D'un autre point de vue, si vous ne voulez pas exposer "trop" pour @Inject, Vous pouvez simplement conserver vos beans gérés @ManagedBean. C'est comme protected contre public. Mais ça ne compte pas vraiment.
Au moins, dans JSF 2.0/2.1, le principal inconvénient de la gestion des beans de support JSF par CDI est qu’il n’existe pas d’équivalent CDI de @ViewScoped. Le @ConversationScoped Se rapproche, mais nécessite toujours un démarrage et un arrêt manuels et ajoute un paramètre de requête laid cid aux URL de résultat. MyFaces CODI facilite les choses en établissant un pont transparent entre le javax.faces.bean.ViewScoped De JSF et le CDI afin que vous puissiez simplement faire @Named @ViewScoped, Mais cela ajoute un paramètre de requête windowId déplaisant aux URL de résultats, également sur plain Vanilla navigation de page en page. OmniFaces résout tout cela avec un vrai CDI @ViewScoped qui lie vraiment la portée du bean à l'état d'affichage JSF au lieu d'un paramètre de requête arbitraire.
JSF 2.2 (qui est publié 3 ans après cette question/réponse) propose une nouvelle annotation @ViewScoped Entièrement compatible CDI dans la boîte au format javax.faces.view.ViewScoped. JSF 2.2 est même livré avec un @FlowScoped Uniquement sur CDI qui n'a pas d'équivalent @ManagedBean, Poussant ainsi les utilisateurs de JSF vers CDI. On s’attend à ce que @ManagedBean Et ses amis soient déconseillés conformément à Java EE 8. Si vous utilisez encore @ManagedBean, Il est donc vivement recommandé de changer CDI est facilement disponible dans Java) conteneurs compatibles avec le profil Web EE, tels que WildFly, TomEE et GlassFish. Pour Tomcat, vous devez l’installer séparément, exactement comme vous l'avez déjà fait pour JSF Voir aussi Comment installer CDI dans Tomcat?
Avec Java EE 6 et CDI, vous avez une option différente pour les beans gérés).
@javax.faces.bean.ManagedBeanFait référence à JSR 314 et a été introduit avec JSF 2.0. L'objectif principal était d'éviter que la configuration du fichier faces-config.xml utilise le bean dans une page JSF.@javax.annotation.ManagedBean(“myBean”)est défini par JSR 316. Il généralise les beans gérés par JSF pour une utilisation ailleurs dans Java EE@javax.inject.Named(“myBean”)sont presque identiques à celui ci-dessus, sauf que vous avez besoin d'un fichier beans.xml dans le dossier web/WEB-INF pour activer CDI.
J'utilisais CDI dans GlassFish 3.0.1, mais pour le faire fonctionner, je devais importer le framework Seam 3 (Weld). Cela a plutôt bien fonctionné.
Dans GlassFish 3.1, CDI a cessé de fonctionner et Seam Weld a cessé de fonctionner avec. J'ai ouvert un bug sur ceci mais je ne l'ai pas encore vu corrigé. Je devais convertir tout mon code en utilisant les annotations javax.faces. *, Mais je prévois de revenir à CDI une fois que cela fonctionnera.
Je conviens que vous devriez utiliser CDI, mais un problème que je n'ai pas encore vu résoudre est ce qu'il faut faire avec l'annotation @ViewScoped. J'ai beaucoup de code qui en dépend. Il n'est pas clair si @ViewScoped fonctionne si vous n'utilisez pas @ManagedBean avec ce dernier. Si quelqu'un peut clarifier cela, je l'apprécierais.
Une bonne raison de passer à CDI: vous pourriez avoir une ressource commune à la session (profil utilisateur par exemple) @Inject Dans les deux beans gérés JSF et REST (c'est-à-dire , Jersey/JAX-RS).
D'autre part, @ViewScoped Est une raison impérieuse de rester avec JSF @ManagedBean - en particulier pour tout ce qui a une AJAX importante. Il n'y a pas de remplacement standard pour cela dans CDI.
On dirait qu’elle supporte peut-être une annotation semblable à @ViewScoped Pour les beans CDI, mais je n’ai pas joué personnellement avec elle.