Comprendre le JSF comme un cadre de CVM
je lis sur JSF et je me sens un peu confus pourquoi JSF est un cadre MVC (ou au moins quelles parties appartiennent à quelle"lettre").
j'ai regardé cette question: Quels sont les éléments MVC dans le cadre MVC JSF?
j'ai lu ici si vous ne le regardez pas dans une vue agrégée le model est votre entity, la vue est votre code XHTML et le controller est le bean managé. Hum...Ok, mais la vue ne dépend pas très souvent de effectuer d'autres appels logiques d'affaires qui renvoie un ensemble d'entités par exemple, la description convient-elle encore?
un livre que j'ai lu l'a décrit comme haricots gérés est une sorte de" message " porteur que les Faces Servlet (contrôleur) utilisent pour invoquer la couche d'affaires (Modèle) et puis le code XHTML est la vue.
il y a tant d'explications et de différences que je ne sais pas lesquelles ou comment les comprendre.
4 réponses
une partie de la raison pour laquelle il est souvent pas tout à fait clair dans JSF et de nombreux autres cadres web que les parties de celui-ci correspondent à quelle partie 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 noeuds M, V et c sont un graphe connecté maximum, ce qui signifie que chaque partie peut communiquer avec chaque autre partie. Par exemple: si le modèle change, il peut pousser ce changement dans la vue. Cela est particulièrement visible dans le cas où plusieurs représentations de la vue dans une application de bureau. Modifiez l'un d'eux, et voyez l'autre mise à jour en temps réel.
en raison de la nature client/serveur et requête/réponse des applications web, MVC classique ne fait pas la carte 1:1 à la plupart des cadres web.
plus précisément, dans JSF la cartographie est la suivante:
- modèle - les services/Oad plus les entités qu'ils produisent et consomment. Entrée point à cela est le bean géré, mais en Java EE (dont JSF est une partie) ces artéfacts sont généralement mis en œuvre par EJB et JPA respectivement.
- View - les composantes de L'UI et leur composition en une page complète. Ceci est entièrement dans le domaine de JSF et mis en œuvre par JSF
UIComponents et Facelets respectivement. - contrôleur - le contrôleur de trafic qui traite les commandes et les données entrantes de l'utilisateur l'achemine vers les bonnes parties et sélectionne une vue pour affichage. Dans JSF on n'écrit pas ce contrôleur, mais il est déjà fourni par le framework (c'est le
FacesServlet).
surtout la dernière partie est souvent mal comprise: dans JSF vous ne mettez pas en œuvre un contrôleur. Par conséquent, un haricot de soutien ou tout autre type de haricot géré est pas le contrôleur.
La première partie (le modèle) est aussi pas toujours clairement compris. La logique opérationnelle peut être mise en œuvre 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 aussi là que le nom de l'une des phases du cycle de vie du JSF vient: Update Model . Dans cette phase, JSF introduit les données des composantes de L'UI dans le modèle. En ce sens, (JSF) haricots gérés sont donc le modèle.
bien que JSF elle-même ne définisse pas explicitement le concept, il existe un utilisation souvent récurrente et spécifique des fèves gérées appelé le fèves de soutien .
pour JSF un support est encore le modèle, mais pratiquement c'est un élément de plomberie qui se trouve au milieu du modèle, vue et contrôleur. Car il effectue certaines tâches qui peuvent être considérés comme certains le contrôleur de tâches, c'est souvent à tort d'être 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 à l'occasion faire une " vue logique.
voir aussi:
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 Managés.
JSF vous donne le pouvoir de contrôler vos requêtes/réponses. La façon dont vous créez le model/view n'est pas directement liée au concept MVC framework. C'est juste une question de choix. Le concept de MVC est lié à l'organisation du code.
Struts analogiquement est un MVC framework, mais il fonctionne principalement comme un contrôleur.
je pense que je vous aide à clarifier votre idée.
ce qui est intéressant à propos de l'idée de fève gérée , c'est qu'elle peut être utilisée à la fois comme modèle (MVC pattern) ou comme contrôleur ( mediating-controller MVC pattern , aussi appelé model-view-adaptateur), 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 commerciale est contenue dans le bean géré et le modèle est strictement un modèle de domaine. Nous avons alors:
-
modèle - contient le modèle de domaine, dans la plupart des cas représente les tableaux dans la base de données, a persisté par les OAD.
-
View - les composantes de l'ui, reliées à la fève;
-
Contrôleur - le managed bean qui contient la logique métier et gère la communication entre le point de vue et modèle.
je pense que certaines personnes confondent médiateur-contrôleur MVC comme simple MVC, ce qui conduit aux différentes explications rencontrées.
je pense, tous les anwsers ici sont corrects. Mais le principal point de confusion provient pour moi du mélange des définitions des composants mvc provenant du framework, ici JSF, avec ces composants de modèle et de contrôleur que vous définissez dans votre conception d'application:
Supposons que vous passez de JSF à n'importe quel autre cadre D'UI Web dans votre application d'affaires: Vous aurez toujours un "modèle d'affaires" et un "business controller". (Dans nos projets, nous appelons simplement ces composants "le modèle" et "processus.") Qu'est-ce que cela signifie: soit vous ne pouvez pas utiliser mvc pour la description de l'architecture d'application globale, mais uniquement pour L'interface utilisateur, ou vous pouvez devoir accepter de nombreux controller, model comme des composants dans votre pile d'application complète.