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.