Version imprimable
Bonjour tout le monde,
J'ai une petite ambiguïté en ce qui concerne le Modèle 2 ou plutôt pourquoi ce nom?
Sur pleins de tutos j'ai lu que les managed-bean sont inclus dans la partie MODEL, d'autres tutos expliquent comme quoi les managed-bean font partie du CONTROLLER.
Des avis?:mrgreen:
Pour moi managedBeand c'est le MODEL, le controleur pour ma part est la FacesServlet, c'est elle qui prend les entrées de l'utilisateur les transforment et les passent au Model..
souvent on mélange managedBean et backingBean, le backingBean quant à lui est plus proche de la View que du MODEL, normalement, on y met que l'image 'object' de la vue, et pas le comportement de l'application..
Dans ce cas le MODEL sera composé de : la couche service, la couche DAO et les managed-bean? c'est ça à ton avis qui illustre la nomination MODEL 2?
Citation:
Envoyé par Sniper37
le MODEL 2 c'est le MVC2, la différence avec MVC est que le 2 dispose d'une seule servlet principale qui fait l'office du Controller..:roll:, comme Struts et JSF..
c'est de ça que tu parles?
Beh moi je me demande pourquoi le 2 du MODEL 2?
tu es sûr @Sniper37 de ton explication?
Citation:
Envoyé par Sniper37
Salut,
Le 2 vient du fait qu'il y'a un model 1 (bien évidemment :aie:), et model n'est autre que "modèle", comme pour uen voituure ...
Bref, Sun avait proposé une première solution pour structurer le développement Web avec Java via le model 1, à base de JSPs et de beans :
http://java.sun.com/developer/techni...s_jsp/fig2.gif
Puis avait rectifié le tir avec un second modèle de développement, le model 2:
http://java.sun.com/developer/techni...s_jsp/fig3.gif
Bref, tout est dans cette page : http://java.sun.com/developer/techni.../servlets_jsp/
Sinon, personnellement, je considère les managed beans comme faisant partie de la couche contrôle et non pas model ...
Dans le second schéma, ça correspond au carré rouge, JavaBeans (Model).
Ca peut être considéré comme la partie model de la couche contrôle/présentation (VC), mais je pense qu'ils font pas partie de la couche Model globale de l'application : ils sont là uniquement pour faire une sorte d'adaptateur entre les vues et le backend, voilà. Ils n'effectuent (ou du moins ne devraient pas) ni de logique métier ni représentent les entités qui modélisent notre domaine.
C'est exactement ce que j'avais compris!
Mais je n'ai pas eu de réponse claire ailleurs.
Allez d'autre avis :aie:
Citation:
Envoyé par djo.mos
Je pense que ce n'était pas la proposition de Sun, mais, de la première version du livre design pattern du go4.Citation:
Envoyé par djo.mos
tu mets quoi dans le partie MODEL? tu n'est pas entrain de parler des backing bean?Citation:
Envoyé par djo.mos
normalement la logique métier n'est pas dans la partie MVC, plutot dans la couche métier (Business Layer Tier).
Au fait, j'ai associé les beans au MODEL au lieu du contrôleur parceque c'est le framework JSF qui gère la mise à jour de la vue dans le cycle de vie JSF, et c'est lui qui reçoit en premier lieu la requete.
ces notions peuvent changer suivant l'architecture de l'application, et mainetenant l'utilisation d'hibernate et spring et binding direct dans la vue d'objects métier ou de DAO supprime des couches..
Justement, c'est là qu'on est pas d'accord : je considère que le MVC englobe toute l'application et non pas seulement la partie web [et je ne suis pas le seul].Citation:
Envoyé par Sniper37
D'ailleurs, je considère qu'un framework Web (JSF entre autres) ne s'occupe que des partie VC, et qu'il touche pas (ou du moins devrait pas) toucher à l partie Model qui elle est agnostique à la technologie de présentation et/ou aux clients (web, client lourd, webservices, etc.)
Je ne comprends pas le passage ... je veux dire ok, je suis d'accord pour la seconde partie, mais je comprends pas comment à partir de cette thèse tu en déduis que les BB font partie du model ? :koi:Citation:
Au fait, j'ai associé les beans au MODEL au lieu du contrôleur parceque c'est le framework JSF qui gère la mise à jour de la vue dans le cycle de vie JSF, et c'est lui qui reçoit en premier lieu la requete.
Oui et non : aucun framework web (ou plus précisément technologie de présentation) n'est assez flexible pour s'adapter à n'importe quel backend :Citation:
Envoyé par Sniper37
- Struts 1 impose le passage par les Action et actionForms
- Struts 2, JSF, WebWork, etc. sont beaucoup plus flexibles et permettent d'utiliser les objet métier directement, n'empêche qu'ils imposent des restrictions (genre la sugnature d'une action en JSF, l'impossiblité de passage de paramètres dans EL, etc.)
Tu auras toujours besoin d'une couche même toute mince pour adapter ton backend au front-end, et c'est là qu'entre en jeu la partie Controller, et tu resteras toujours en MVC.
Ok, je comprend , tu as tout a fait raison, d'ailleurs, j'utilise la même architecture, mais, cela ne veux pas dire que le pattern J2EE avec MVC et couche métier séparés devient caduc, on ne peut pas toujours fusionner fusionner le MVC et la couche métier, ce qui me gène au fait, c'est le mélange de la logique métier dans un objet JSF, ce qui provoque un couplage fort entre le client et les services métiers.Citation:
Envoyé par djo.mos
Je me base juste de la définition du Controller:Citation:
Envoyé par djo.mos
J'estime que le Controller reste la FacesServlet, en mettant dans le controller un bean que tu associe à une ou plusieurs pages, cela ressemble plus au MVC1: un controllerpour chaque page..Citation:
Controller - The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.
Je suis tout a fait d'accord :D.Citation:
Envoyé par djo.mos
:arrow: Je ne sais pas si tu différencie la notion du managedBean et celle du BackingBean?
Non, on ne se comprend pas :PCitation:
Envoyé par Sniper37
J'ai dit que pour moi, le M du MVC est la partie métier, je ne vois pas comment on pourrait fusionner MVC et la couche métier (ça donnerait MMVC si on suit ma logique :mrgreen:)
A moins bien sûr qu'on parle d'un projet répartie ou tu as des services distants et une partie façade dans l'application Web par exemple.
+1Citation:
ce qui me gène au fait, c'est le mélange de la logique métier dans un objet JSF, ce qui provoque un couplage fort entre le client et les services métiers.
Ok. Je te l'accorde, cette définition englobe nos 2 points de vues :Citation:
Je me base juste de la définition du Controller:
- Que le model est "les managed beans" :
Si tu considères que "business processes" représente la couche services (métier). Dans ce cas, la chose qui active la couche service n'est pas la couche service, et donc le model est différent de la couche service et métier.Citation:
The actions performed by the model include activating business processes
- Ou que "les managed beans" fot partie du controller : Mais on peut aussi considérer que "business processes" représente plutôt l'aspect logique de la chose (comme la logique métier), comme pour dire que la couche service applique ou implémente la logique métier. Donc, le controlleur invoque le model, or dans JSF ce qui invoque la couche service sont les managed beans.
Pas compris ... mais tu peux réutiliser un mùeêm maanged beans dans plusieurs pages, et utiliser plusieurs managed beans dans une même page ...Citation:
J'estime que le Controller reste la FacesServlet, en mettant dans le controller un bean que tu associe à une ou plusieurs pages, cela ressemble plus au MVC1: un controllerpour chaque page..
Non. J'utilise managed bean et backing bean pour désigner la même chose, ces beans là qu'on déclare dans faces-config ...Citation:
:arrow: Je ne sais pas si tu différencie la notion du managedBean et celle du BackingBean?
Ce que je voulais dire ici, c'est que ça ressemble plus au Modèle 1 du MVC:Citation:
Envoyé par djo.mos
un controller -> une page
le Modèle 2:
un controller -> toute les pages.
j'ai l'habitude de séparer les deux, ce n'est pas évident, mais le backing bean est censé représenter les composants JSF coté serveur, il doit être à l'image de la page, le managed-bean, qui est géré par JSF ne contient pas les objetcs de composants, mais, réalise la logique applicative, ou logique métier.Citation:
Envoyé par djo.mos
Le but est de séparer le frontend de la logique applicative ou métier.
J'avais un lien qui explique bien la différence des deux, mais, je ne le retrouve pas. j'ai trouvé par contre cette discussion
ça serait intéressant de faire un genre de best practices pour JSF ;)
perso j'en suis à mon deuxième projet projet jsf en 3 ans (icefaces), spring, hibernate et j'en arrive à la conclusion que ca restea toujours confus :mouarf:
car ou commence la logique métier et la fin du managed bean ... le managed ne doit que faire de déléguer à la couche de services
mais de ce que j'ai vu en terme d'archi et de développement c'est pas respecté ...
La confusion me fait éclaircir des choses moi :aie:.
Voilà j'ai ce que j'ai pu comprendre en lisant certains tutos qui parlent de l'architecture sous JSF: c'est que la notion de MODEL dans le MVC2 a deux façades : un modèle propre à la partie JSF (c'est le MV : pour gérer les données saisies par l'utilisateur ou pour récupérer des données provenant de la partie métier pour les afficher à l'écran) et un modèle métier (comme les classes de mappings des tables de la base de données) et qui n'a rien à voir avec la logique JSF.
Explication :
N.B: Ces explication proviennent d'un tuto que j'ai trouvé sur internet:mrgreen:Citation:
Pour chaque use case on retrouve :
* des pages JSP,
* un managed bean vue qui contient les références vers les composants JSF,
* un managed bean modèle qui contiendra les données liées à la vue,
* un managed bean contrôleur qui réalise toutes les opérations,
* Le managed bean controller
Ce bean est à mettre en scope session car il sera utilisé tout au long de l'utilisation du
use-case.
Détail du contenu :
une instance du BeanView,
une instance du BeanModel,
leurs méthodes get et set,
les méthodes actions qui répondent aux événement utilisateurs et permettent la navigation, les méthodes event listener qui permettent de gérer des évènements utilisateurs, les méthodes permettant d'effectuer une validation des ensembles.
* Le managed bean View
Ce bean contient toutes les références, vers les composants JSF, nécessaires au fonctionnement de l'application. Les attributs sont bindés aux composants dans les JSP via l'attribut binding="…" des composants.
Détail du contenu :
des propriétés de type UIComponent,
des méthodes get et set pour ces propriétés.
* Le managed bean Model
Ce bean contient toutes les données à afficher ou saisie dans la vue. En général on
stockera des DTO ou des collections de DTO provenant de l'EJB session façade de
l'application. Ces données sont liées via l'attribut value="…" des composants JSF.
Détail du contenu :
Les données à afficher ou saisie dans la vue, on privilégiera l'utilisation directe de DTO afin de faciliter le dialogue avec les EJB session façade.
Les getters et setters Les méthodes de validation associés à ces données.
Schéma
Ce schéma montre de façon générale le contenu de chaque bean ainsi que la relation qu'il possède avec chacun des autres beans.
Le lien entre le bean controller et les beans model et view se fait par composition, les instanciation seront gérée par JSF en déclarant les beans model et view comme des managed properties du bean controller :