Comprendre JSF en tant que framework MVC
Je lis sur JSF et je me sens plutôt confus pourquoi JSF est un framework MVC (ou au moins quelles parties appartiennent à quelle "lettre").
J'ai regardé cette question: Quels sont les composants MVC dans le framework JSF MVC?
J'y lis 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 bean géré. Hmm ... D'accord, mais la vue ne dépend-elle pas très souvent de l'exécution d'autres appels de logique métier qui retournent un ensemble d'entités par exemple, la description correspond-elle toujours?
Un livre que j'ai lu le décrit comme des beans gérés est une sorte de porteur de "message" que le servlet Faces (contrôleur) utilise pour appeler la couche métier (modèle), puis le code XHTML est la vue.
Il y a tellement d'explications et de différences donc je ne sais pas quoi ni comment le comprendre.
Une partie de la raison pour laquelle il n'est souvent pas entièrement clair dans JSF et dans de nombreux autres frameworks Web quelles parties de celui-ci correspondent à quelle partie de MVC, c'est que le modèle MVC a été initialement conçu pour les applications de bureau.
Dans une application de bureau, les nœuds M, V et C sont un graphe connecté maximum, ce qui signifie que chaque partie peut communiquer avec toutes les autres parties. Par exemple. si le modèle change, il peut pousser cette modification à la vue. Cela est particulièrement visible dans le cas où il existe plusieurs représentations de la vue dans une application de bureau. Modifiez l'un et voyez l'autre mise à jour en temps réel.
En raison de la nature client/serveur et demande/réponse des applications Web, MVC classique ne mappe pas 1: 1 à la plupart des cadres Web.
Plus précisément, dans JSF, le mappage est le suivant:
- Modèle - Les services/DAO plus 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 implémentés respectivement par EJB et JPA.
- Afficher - Les composants de l'interface utilisateur et leur composition dans une page complète. Ceci est entièrement dans le domaine de JSF et implémenté par JSF
UIComponents et Facelets respectivement. - Contrôleur - Le flic du trafic qui gère les commandes et les données entrantes de l'utilisateur, les achemine vers les bonnes parties et sélectionne une vue à afficher. En JSF, on n'écrit pas ce contrôleur, mais il est déjà fourni par le framework (c'est le
FacesServlet).
En particulier, la dernière partie est souvent mal comprise: dans JSF, vous n'implémentez pas de contrôleur. Par conséquent, un bean de sauvegarde ou tout autre type de bean géré est [~ # ~] et non [~ # ~] le contrôleur.
La première partie (le modèle) n'est pas non plus toujours bien comprise. 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 également de là que vient le nom d'une des phases du cycle de vie du JSF: Update Model. Dans cette phase, JSF transfère les données des composants de l'interface utilisateur dans le modèle. En ce sens, les beans gérés (JSF) sont donc le modèle.
Bien que JSF lui-même ne définisse pas explicitement le concept, il existe une utilisation souvent récurrente et spécifique des beans gérés appelés bean de sauvegarde .
Pour JSF, un bean de sauvegarde est toujours le modèle, mais pratiquement c'est un élément de plomberie qui se trouve au milieu du modèle, de la vue et du contrôleur. Puisqu'il exécute certaines tâches qui peuvent être considérées comme des tâches de contrôleur, il s'agit souvent à tort du contrôleur. Mais, comme expliqué précédemment, ce n'est pas correct. Il peut également effectuer certaines tâches de modèle et parfois effectuer également une logique d'affichage.
Voir également:
Dans une forme minimaliste, c'est:
- Modèle: tout ce que vous utilisez pour la persistance (Hibernate, JPA, etc.) et la modélisation de données (Java Beans).
- Affichage: xhtml, jsp, etc.
- Contrôleur: Haricots gérés.
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 de framework MVC. C'est juste une question de choix. Le concept MVC est lié à l'organisation du code.
Analogously Struts est un framework MVC, mais il fonctionne principalement comme un contrôleur.
Je pense que je vous aide à mieux clarifier votre idée.
L'idée intéressante du bean géré est qu'il peut être utilisé à la fois comme modèle (modèle MVC) ou comme contrôleur ( modèle MVC du contrôleur de médiation , également appelé adaptateur de vue de modèle), 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 bean géré et le modèle est strictement un modèle de domaine. On a alors:
Modèle - contient le modèle de domaine, dans la plupart des cas, représente les tables de la base de données, persisté via les DAO.
Voir - les composants ui, connectés au bean;
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 de contrôleur de médiation comme MVC simple, ce qui conduit aux différentes explications rencontrées.
Je pense que toutes les réponses ici 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 de modèle et de contrôleur que vous définissez dans la conception de votre application: