Comprendre JSF comme un cadre MVC

Question

Je suis en train de lire sur JSF et je ne comprends pas bien pourquoi JSF est un framework MVC (ou du moins quelles parties appartiennent à quelle "lettre").

Je me suis penché sur cette question : Quels sont les composants MVC dans le cadre JSF MVC ?

J'ai lu que si vous ne le regardez pas dans une vue agrégée, le modèle est votre entité, la vue est votre code XHTML et le contrôleur est le haricot géré. Hmm...Ok, mais la vue ne dépend-elle pas très souvent de l'exécution d'autres appels de logique métier qui renvoient un ensemble d'entités par exemple, la description correspond-elle toujours ?

Un livre que j'ai lu le décrivait comme des haricots gérés qui sont une sorte d'apporteur de "message" que le servlet Faces (contrôleur) utilise pour invoquer la couche métier (modèle) et ensuite le code XHTML est la vue.

Il y a tellement d'explications et de différences que je ne sais pas laquelle ou comment la comprendre.

Answer 1

La raison pour laquelle il n'est pas toujours évident de savoir quelles parties de JSF et de nombreux autres frameworks web correspondent à quelles parties de MVC, est que le modèle MVC a été conçu à l'origine pour les applications de bureau.

Dans une application de bureau, les nœuds M, V et C forment un graphe à connexion maximale, ce qui signifie que chaque partie peut communiquer avec toutes les autres parties. Par exemple, si le modèle change, il peut transmettre ce changement à la vue. Ceci est particulièrement visible dans le cas où il y a plusieurs représentations de la vue dans une application de bureau. Modifiez-en une et voyez les autres se mettre à jour en temps réel.

En raison de la nature client/serveur et demande/réponse des applications web, le MVC classique ne correspond pas à la plupart des frameworks web.

Plus précisément, dans JSF, le mappage est le suivant :

• Modèle - Les services/DAO ainsi que les entités qu'ils produisent et consomment. Le point d'entrée est le bean géré, mais dans Java EE (dont JSF fait partie), ces artefacts sont généralement mis en œuvre par EJB et JPA respectivement.
• Voir - Les composants de l'interface utilisateur et leur composition en une page complète. Ceci est entièrement dans le domaine de JSF et implémenté par JSF UIComponent et Facelets respectivement.
• Contrôleur - L'agent de circulation qui traite les commandes et les données entrantes de l'utilisateur, les achemine vers les bonnes parties et sélectionne une vue à afficher. Dans JSF, on n'écrit pas ce contrôleur, mais il est déjà fourni par le framework (c'est la fonction FacesServlet ).

En particulier, la dernière partie n'est souvent pas bien comprise : dans JSF, vous n'implémentez pas de contrôleur. Par conséquent, un backing bean ou tout autre type de bean géré est un contrôleur. PAS le contrôleur.

La première partie (le modèle) n'est pas toujours bien comprise non plus. La logique métier peut être implémentée par EJB et JPA, mais du point de vue de JSF, tout ce qui est référencé par une liaison de valeur est le modèle. C'est d'ailleurs de là que vient le nom de l'une des phases du cycle de vie de JSF : Update Model . Dans cette phase, JSF pousse les données des composants de l'interface utilisateur vers le modèle. En ce sens, les managed beans (JSF) sont donc le modèle.

Bien que JSF lui-même ne définisse pas explicitement le concept, il existe une utilisation spécifique et souvent récurrente des managed beans appelée le haricot de soutien .

Pour JSF, un backing bean est toujours le modèle, mais en pratique, c'est un élément de plomberie qui se trouve au milieu du modèle, de la vue et du contrôleur. Parce qu'il effectue certaines tâches qui peuvent être considérées comme des tâches de contrôleur, il est souvent confondu avec le contrôleur. Mais, comme expliqué précédemment, ce n'est pas correct. Il peut également effectuer certaines tâches de modèle et, occasionnellement, de la logique de vue.

Voir aussi :

• Quels sont les principaux avantages du modèle MVC par rapport à l'ancien modèle à trois couches ?
• MVC-Architecture de JavaServer Faces (chapitre 4.3)

Answer 2

Sous une forme minimaliste, c'est :

• Modèle : Tout ce que vous utilisez pour la persistance (Hibernate, JPA, etc.) et la modélisation des données (Java Beans).
• Affichage : xhtml, jsp, etc.
• Contrôleur : Mananaged Beans.

JSF vous donne le pouvoir de contrôler vos demandes/réponses. La façon dont vous créez le modèle/la vue n'est pas directement liée au concept MVC du framework. C'est juste une question de choix. Le concept MVC est lié à l'organisation du code.

De manière analogue, Struts est un framework MVC, mais il fonctionne principalement comme contrôleur.

Je pense que je vous aide à mieux clarifier votre idée.

Answer 3

Ce qui est intéressant dans l'idée du managed bean, c'est qu'il peut être utilisé à la fois comme un modèle (modèle MVC) ou comme un contrôleur ( contrôleur médiateur modèle MVC (également appelé adaptateur modèle-vue), où le modèle et la vue n'interagissent pas directement.

Dans ce dernier cas, le mécanisme de routage n'est pas le contrôleur, car la logique métier est contenue dans le haricot géré et le modèle est strictement un modèle de domaine. Nous avons alors :

• Modèle - contient le modèle de domaine, qui représente dans la plupart des cas les tables de la base de données, persistées par des DAO.

• Voir - les composants de l'interface utilisateur, connectés au haricot ;

• Contrôleur - le bean géré qui contient la logique métier et gère la communication entre la vue et le modèle.

Je pense que certaines personnes confondent MVC médiateur-contrôleur et MVC ordinaire, ce qui conduit aux différentes explications rencontrées.

Answer 4

Je pense que toutes les réponses sont correctes. Mais le principal point de confusion vient pour moi du mélange des définitions des composants mvc provenant du framework, ici JSF, avec les composants modèle et contrôleur que vous définissez dans la conception de votre application :

Supposons que vous passiez de JSF à tout autre framework d'interface utilisateur Web dans votre application métier : Vous aurez toujours un "modèle métier" et un "contrôleur métier". (Dans nos projets, nous appelons simplement ces composants "le modèle" et "le processus").

Qu'est-ce que cela signifie ? Soit vous ne pouvez pas utiliser mvc pour la description de l'architecture globale de l'application, mais uniquement pour l'interface utilisateur, soit vous devrez accepter de nombreux composants de type contrôleur, modèle dans votre pile d'applications complète.