JSF2 - soutenu par EJB ou ManagedBean?

Question

Comme j'apprends JSF2, je réalise que je ne suis pas sûr de ce que les éléments d'appui doivent être. Du point de vue de la conception, quelle est la différence entre EJBs et @ManagedBeans?

En fin de compte, je vais utiliser JPA, donc EJB est un choix naturel pour la couche d'affaires. Est-ce une bonne pratique d'utiliser EJB directement à partir de JSF (comme expliqué )?

En ce moment je me penche vers l'utilisation @ManagedBeans pour les composants qui ne nécessitent pas l'accès à la couche d'affaires (par exemple des aides de vue) ou traitent des données demande / session. Pour d'autres fins, par exemple liste quelque chose dans une grille, j'accéder directement EJB.

Est-ce une bonne conception? Dois-je utiliser @ManagedBeans pour tous les haricots supports pour la cause de la séparation de la couche propre, même si, dans certains cas, ils délèguent uniquement EJB?

Answer 1

question très valable, mais je suppose que la réponse dépend de la « rigueur » de l'approche de votre projet. Il y a en effet un peu de redondance entre backing bean JSF et EJB à la fois mettre en œuvre une logique métier.

Dans idéal l'utilisation des fonctionnalités de JSF avec converters, rendered, validator, etc. le backing bean pourrait en effet code propre logique métier. Mais dans la pratique une certaine logique liées présentation des fuites souvent en elle.

Cette logique liée présentation devrait idéalement ne pas être dans un EJB. Cette logique liée présentation peut dépendre du paquet visages, mais pas nécessaire. Il est ce qu'il fait qui en font la présentation liée ou non.

Un modèle de composant unifié a quelques avantages bien. Et il est l'approche adoptée par Seam et Spring . Dans les deux cas, le composant d'affaires avec déclarative des transactions, etc. peuvent être utilisés directement dans JSF (Spring ne pas utiliser EJB mais fournir un modèle similaire). EJB puriste cependant dire que vous devez dissocier les deux.

Donc, pour moi, c'est finalement une question de goût et la taille du projet. Je peux imaginer que pour un petit / projet à moyen utilisant EJB dans JSF fonctionne très bien. Pour un plus grand projet où cette critique est de rigueur, assurez-vous de ne pas visser les couches.

Answer 2

En Java EE 6 il y a un certain chevauchement entre les différents haricots gérés: beans gérés JSF (@ManagedBean), CDI a réussi les haricots (@Named) et les haricots EJB (@Stateless, @Statefull, @Singleton)

.

Dans la couche de vue, je ne vois aucun avantage particulier pour coller avec @ManagedBean. La variante CDI @Named semble être en mesure de faire la même chose et plus, par exemple vous donner accès à la portée de conversion.

La pensée actuelle semble être que finalement le modèle de composants EJB sera également installé ultérieurement comme un ensemble d'annotations CDI. En particulier, membre du groupe d'experts Reza Rahman fait allusion souvent à ce sujet. Voir par exemple Injection Dépendance en Java EE 6 - Partie 1

Pour le moment cela n'a pas eu lieu, alors EJB haricots restent le meilleur endroit pour mettre la logique métier, surtout quand JPA est utilisé pour la persistance.

Cependant, si oui ou non IDC obtenir les capacités d'EJB, à mon humble avis, il est toujours préférable d'utiliser un haricot séparé pour le concept de « sauvegarde haricot » et un haricot séparé pour la « logique métier ».

Le backing bean peut être très mince, juste contenant quelques références à modéliser des objets et services (EJB). Action Méthodes du backing bean peut déléguer presque directement aux services, mais leur valeur ajoutée est de fournir à l'utilisateur des commentaires (en ajoutant FacesMessages sur le succès ou l'échec) et de faire des petites modifications de l'interface utilisateur (par exemple, la fixation d'un booléen false qui affiche une boîte de dialogue) .

Les Services (logiques d'affaires) ne doivent pas rien savoir sur une présentation particulière. Ils devraient être tout aussi bien utilisable à partir de fèves de support JSF, JAX-RS, Servlets, les clients distants autonomes Java SE ou autre.

Même si tous les haricots deviendraient des haricots CDI, cela ne change pas cette division fondamentale de la responsabilité.

Answer 3

Un article intéressant, ne savait à ce sujet. Cependant, pour moi cet article sent plus comme une diatribe vers JSF géré les haricots. Il a également découple serrés EJB avec JSF. Il est peut-être intéressant dans les petites applications (personnelles), mais probablement pas dans les applications du monde réel SOA où vous souhaitez avoir un contrôle total sur l'entretien a été EJB.

Quant à celui à utiliser pour quoi, je voudrais juste coller à @ManagedBean pour désigner un modèle JSF --which est lié à un ou des vues JSF plus spécifiques. Vous pouvez parfaitement utiliser @EJBs pour la logique métier spécifique non JSF et / ou datamodels. Vous pouvez injecter @EJBs dans un modèle JSF et déléguer dans les méthodes d'action et peut-être aussi getters / setters, mais vous ne devriez pas faire l'inverse, à savoir ne pas définir le modèle JSF dans un @EJB, ce qui conduit à un couplage étroit et ferait @EJBs unuseable en dehors du contexte de JSF. En ce qui concerne, votre conception sonne bien, aussi longtemps que vous regardez à ne pas importer quoi que ce soit du paquet javax.faces dans la classe @EJB.

Answer 4

En appelant EJB à partir de votre XHTML, vous introduisez un couplage étroit entre le choix de la mise en œuvre dans la vue et de niveau entreprise.

Si vous utilisez un haricot réussi à appeler un EJB, [ou même, mettre dans un délégué de l'entreprise], vous pourrez changer votre niveau d'activité complètement à ressort sans affecter la couche de vue (XHTML).

Est est techniquement possible, et très facile pour vous (JSR 299) pouvoir utiliser EJB en tant que votre bean géré, et qui est probablement ce que ces vendeurs veulent que vous fassiez - obtenir collé à des détails. Mais que ce soit une bonne chose à faire? -. Non