Comprendre JSF comme cadre MVC

Je suis en train de lire sur JSF et je suis plutôt confus de savoir pourquoi JSF est un framework MVC (ou au moins quelles parties appartiennent à quelle “lettre”).

J’ai regardé cette question: Quels composants MVC dans le framework JSF MVC?

Je lis là-bas 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 … Ok, mais la vue ne dépend-elle pas très souvent de la réalisation d’autres appels à la logique métier qui renvoient un ensemble d’entités par exemple, la description convient-elle toujours?

Un livre que j’ai lu l’a décrit comme étant un type de message que le serveur Servlet (Controller) utilise pour appeler la couche de gestion (modèle) et le code XHTML est la vue.

Il y a tellement d’explications et de différences que je ne sais pas comment ni comment le comprendre.

Une des raisons pour lesquelles JSF et de nombreux autres frameworks Web ne correspondent pas toujours à la partie de MVC réside dans le fait que le modèle MVC a été conçu à l’origine pour les applications bureautiques.

Dans une application de bureau, les nœuds M, V et C constituent un graphe connecté maximal, ce qui signifie que chaque partie peut communiquer avec toutes les autres parties. Par exemple, si le modèle change, il peut pousser ce changement dans 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. Changez-en un et voyez l’autre mise à jour en temps réel.

En raison de la nature client / serveur et de la demande / réponse des applications Web, MVC classique ne mappe pas 1: 1 sur la plupart des frameworks 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 consumnt. 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 par EJB et JPA respectivement.
  • 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 UIComponent s et Facelets respectivement.
  • Contrôleur – Agent de trafic qui gère les commandes et les données entrantes de l’utilisateur, les achemine vers les composants appropriés 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 n’est souvent pas bien comprise: dans JSF, vous n’implémentez pas de contrôleur. Par conséquent, un bean backing ou tout autre type de bean géré n’est PAS le contrôleur.

La première partie (le modèle) n’est pas toujours bien comprise. La logique métier peut être implémentée par EJB et JPA, mais du sharepoint vue de JSF, tout ce qui est référencé par une liaison de valeur est le modèle. C’est également ici que provient le nom d’une des phases du cycle de vie JSF: Update Model . Dans cette phase, JSF envoie les données des composants de l’interface utilisateur dans le modèle. En ce sens, les haricots gérés (JSF) sont donc le modèle.

Bien que JSF ne définisse pas explicitement le concept, il existe une utilisation souvent récurrente et spécifique des beans gérés appelés beaning .

Pour JSF, un haricot 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. Comme il exécute certaines tâches qui peuvent être considérées comme des tâches de contrôleur, cela 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 sur le modèle et, de temps en temps, effectuer une logique de vue.

Voir également:

  • Quels sont les principaux avantages du modèle MVC par rapport au modèle à 3 couches
  • Architecture MVC des faces JavaServer (Chapitre 4.3)

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: Haricots managés.

JSF vous donne le pouvoir de contrôler vos demandes / réponses. La façon dont vous créez un modèle / 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 contrôleur.

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

Ce qui est intéressant avec l’idée du bean géré, c’est qu’il peut être utilisé à la fois comme modèle (modèle MVC) ou comme contrôleur ( modèle MVC de contrôleur de médiation , également appelé model-view-adapter). 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 ssortingctement un modèle de domaine. Nous avons alors:

  • Modèle – contient le modèle de domaine, représente dans la plupart des cas les tables de la firebase database, persistantes via les DAO.

  • Voir – les composants d’interface utilisateur, connectés au haricot;

  • Controller – 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 le contrôleur de médiation MVC comme un simple MVC, ce qui conduit aux différentes explications rencontrées.

Je pense que toutes les réponses sont correctes. Mais le principal sharepoint confusion vient du fait que je mélange les 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:

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

Qu’est-ce que cela signifie: Vous ne pouvez pas utiliser mvc pour la description de l’architecture globale de l’application, mais uniquement pour l’interface utilisateur, ou vous devrez peut-être accepter plusieurs composants de type contrôleur dans votre stack d’applications complète.