Discussion :

[elitost]

Bonjour,

Après un discussion hier sur le MVC je voudrais une confirmation :

M = les Form bean manipulées par Struts
V = les écrans d'affichage (jsp)
C = action servlet + strutsconfig.xml

La partie modèle de données dans le sens Java Bean de base + couche DAO est bien décorellées du modèle MVC de Struts ? Le MVC de Struts concerne bien uniquement la partie Struts ?

Merci d'avance.

[petitpasdelune]

Bonjour,
M = les Form bean manipulées par Struts
V = les écrans d'affichage (jsp)
C = action servlet + strutsconfig.xml
La partie modèle de données dans le sens Java Bean de base + couche DAO est bien décorellées du modèle MVC de Struts ? Le MVC de Struts concerne bien uniquement la partie Struts ?

Oui. En fait la partie modèle peut normallement interagir avec n'importe quel framework d'acces aux données. De même que la vue n'est pas limitée aux JSP.

PPDL.

[elitost]

Ok, c'est bien ce que je pensais et ce que j'ai défendu hier.

Merci.

[manblaizo]

M = les Form bean manipulées par Struts
V = les écrans d'affichage (jsp)
C = action servlet + strutsconfig.xml

La partie modèle de données dans le sens Java Bean de base + couche DAO est bien décorellées du modèle MVC de Struts ? Le MVC de Struts concerne bien uniquement la partie Struts ?

Salut !
Euh, une petite précision tout de même. Struts permet de créer des applications web suivant le modèle MVC, mais le modèle MVC ici ne concerne pas uniquement la partie Struts. En fait, en tant que tel, Struts n'implémente que la partie Controller (action servlet + dispatcher...) et un peu la partie View (taglibs jsp), mais pas la partie Model. Struts te permet d'intégrer n'importe quel modèle que tu veux, qui représente donc ici la couche business dans une application multi-couches, développé soit avec des ejb soit avec de simples pojo gérés par Spring. Bien évidemment, tu peux avoir une architecture où tes actions struts ont directement accès à la couche DAO, mais ça c'est un choix de simplification d'architecture, qui ne signifie pas pour autant que le Model fait aussi partie de struts.
Donc, en gros, Struts c'est V+C dans le modèle MVC, et liberté pour le M.
Voilà, j'espère n'avoir pas trop compliqué encore les choses sur cette notion quelquefois un peu ambigue qu'est le modèle MVC.

[elitost]

Salut !
Euh, une petite précision tout de même. Struts permet de créer des applications web suivant le modèle MVC, mais le modèle MVC ici ne concerne pas uniquement la partie Struts. En fait, en tant que tel, Struts n'implémente que la partie Controller (action servlet + dispatcher...) et un peu la partie View (taglibs jsp), mais pas la partie Model. Struts te permet d'intégrer n'importe quel modèle que tu veux, qui représente donc ici la couche business dans une application multi-couches, développé soit avec des ejb soit avec de simples pojo gérés par Spring. Bien évidemment, tu peux avoir une architecture où tes actions struts ont directement accès à la couche DAO, mais ça c'est un choix de simplification d'architecture, qui ne signifie pas pour autant que le Model fait aussi partie de struts.
Donc, en gros, Struts c'est V+C dans le modèle MVC, et liberté pour le M.
Voilà, j'espère n'avoir pas trop compliqué encore les choses sur cette notion quelquefois un peu ambigue qu'est le modèle MVC.

Dans ce cas dans quoi range t'on les form-bean , pour moi dans la partie Model de Struts et non la partie Model des données.

Vos avis ?

[manblaizo]

Dans ce cas dans quoi range t'on les form-bean , pour moi dans la partie Model de Struts et non la partie Model des données.

Il est à noter déjà que les form-bean n'existent plus dans struts2, donc ils ne peuvent pas constituer la partie Model de struts. A mon avis il faut juste les ranger dans la catégorie de "classes utilitaires" permettant à Struts 1.x de récupérer automatiquement les données de formulaires html qui vont être ensuite converties avant d'être envoyées à la partie Model (la couche métier).

[petitpasdelune]

form-beans font parti de la Vue car ils permettent la saisie et la validation des données entrées par l'utilisateur (cf ici)
selon les auteurs.

PPDL.

[djidane39]

suite à cette discutions, je me pose encore quelque question:
- les Action struts font elle parties du contrôleur?
- Sur certaines discutions du net, j'ai remarqué que certains disent que les actions sont du code métier, et d'autre affirme que les action faisant partie du contrôleur ne contient aucun traitement, seulement des appels de code métier se trouvant dans le modèles. Qui croire?
- Donc question qui découle: où mettre le code métier?

Actuellement voici mon schéma qui ressort de mes réflexion:
Vue : pages jsp
Contrôleur :
- local : servelet Struts
- globale : class Action
Modèle :
- Form bean
- Des autres objets de données
- Classe d'accès au données
- Classe métiers

Suis-je en accord avec les recommandation MVC2?

[c_nvy]

Les Actions Struts font bien partie du Contrôleur et si nécessaire, font appel au code métier du Modèle mais ne doivent en aucun cas contenir du code métier.

Quant aux form-beans, comme c'est écrit ici :

Note: While ActionForm beans often have properties that correspond to properties in your Model beans, the form beans themselves should be considered a Controller component. As such, they are able to transfer data between the Model and View layers.

ils sont considérés comme des composants du Contrôleur parce qu'ils permettent le transfert de données entre le Modèle et la Vue.

[djidane39]

.... Ok, dans ma tête, les beans c'est le modèle, mais il est vrai que les forms ne sont pas vraiment des beans...
donc je devrait finalement me retrouver avec l'architecture suivantes:
Vue : pages jsp
Contrôleur :
- local : servelet Struts
- Form bean
- globale : class Action
Modèle :
- Des autres objets de données
- Classe d'accès au données
- Classe métiers

merci!

[c_nvy]

Les JavaBeans font effectivement partie du modèle.
Pour les form-beans, je t'ai donné mon point de vue.
Maintenant, d'après les autres messages, c'est discutable.

[djidane39]

Pour les form-beans, je t'ai donné mon point de vue.
Maintenant, d'après les autres messages, c'est discutable.

En effet il y a beaucoup de discutions à ce sujet, mais tu ne fait que citer le site de la fondation Apache, qui me parait plutôt fiable, et je ne voit pas trop de raison de le contester. Bon après ce ne sont que des recommandation, si certains estime que ce modèle n'est pas correcte, libre à eux de le modifier!

[zalalus]

V : jsps : fonction uniquement d'affichage

C: formbeans +actions+ strutsconfig.xml+validation.xml : routage et controle des données

M : (métier et (ou DAO)) : code métier et ou intéractions avec les bases de données

Dao: optionel : intéractions avec les bases de données.

J'ai travaillé sur 2 frameworks struts et un framework propriétaire, et je suis absolument sur et certain de ce que j'avance.