Discussion :

[JauB]

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?

[Sniper37]

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..

[JauB]

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?

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..

[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.., comme Struts et JSF..
c'est de ça que tu parles?

[JauB]

Beh moi je me demande pourquoi le 2 du MODEL 2?
tu es sûr @Sniper37 de ton explication?

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.., comme Struts et JSF..
c'est de ça que tu parles?

[djo.mos]

Salut,
Le 2 vient du fait qu'il y'a un model 1 (bien évidemment ), 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 :



Puis avait rectifié le tir avec un second modèle de développement, le model 2:



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.

[JauB]

C'est exactement ce que j'avais compris!
Mais je n'ai pas eu de réponse claire ailleurs.
Allez d'autre avis

Salut,
Le 2 vient du fait qu'il y'a un model 1 (bien évidemment ), 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 :



Puis avait rectifié le tir avec un second modèle de développement, le model 2:



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.

[Sniper37]

Salut,
Le 2 vient du fait qu'il y'a un model 1 (bien évidemment ), 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 :

Je pense que ce n'était pas la proposition de Sun, mais, de la première version du livre design pattern du go4.

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.

tu mets quoi dans le partie MODEL? tu n'est pas entrain de parler des backing bean?
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..

[djo.mos]

tu mets quoi dans le partie MODEL? tu n'est pas entrain de parler des backing bean?
normalement la logique métier n'est pas dans la partie MVC, plutot dans la couche métier (Business Layer Tier).

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].

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.)

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.

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 ?

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..

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 :
- 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.

[Sniper37]

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].

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.

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 ?

Je me base juste de la définition du Controller:

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.

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..

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 :
- 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.

Je suis tout a fait d'accord .

Je ne sais pas si tu différencie la notion du managedBean et celle du BackingBean?

[djo.mos]

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,

Non, on ne se comprend pas
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 )
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.

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.

+1

Je me base juste de la définition du Controller:

Ok. Je te l'accorde, cette définition englobe nos 2 points de vues :
- Que le model est "les managed beans" :

The actions performed by the model include activating business processes

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.

- 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.

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..

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 ...

Je ne sais pas si tu différencie la notion du managedBean et celle du BackingBean?

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 ...

[Sniper37]

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 ...

Ce que je voulais dire ici, c'est que ça ressemble plus au Modèle 1 du MVC:
un controller -> une page
le Modèle 2:
un controller -> toute les pages.

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 ...

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.
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

[*alexandre*]

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

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é ...

[JauB]

La confusion me fait éclaircir des choses moi .
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 :

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 :

N.B: Ces explication proviennent d'un tuto que j'ai trouvé sur internet