[MVC]: le Contrôleur [DAO] et le Transfer Object.
Bonjour à tous et toutes,
J'ai une petite question qui me tracasse sérieusement sur la notion de Transfer Object en fait.
Pour ceux qui ne connaissent pas (ou peut-être qui utilisent déjà cette notion sans connaître le nom), voici un lien explicite abordant la notion de Transfer Object:
http://java.sun.com/blueprints/corej...essObject.html
D'après ce que j'ai compris, le Transfer Object est un objet métier, que l'on souhaite transmettre d'une méthode à une autre.
Ainsi, plutôt que de passer à une méthode toute une suite de paramètres représentant les valeurs des attributs d'un objet, et bien on lui passe juste l'objet lui-même pré-renseigné.
Exemple appel de : setUser( ObjetUser) au lieu de setUser(login, passw, ...). Où ObjetUser est de type User, et possède déjà en interne les attributs: login,passw,... renseignés.
Donc très pratique: notamment pas besoin de rajouter ou enlever des paramètres dans la signature de la méthode appelée (ici setUser()), en cas d'ajout ou suppression d'attributs à l'objet. Sans compter le risque d'erreurs (inversion de l'ordre des params,...) que le fait de passer plusieurs params comporte.
Bref, voici, ma, mes questions:
Dans le cadre du modèle MVC utilisant un contrôleur DAO (Data Access Object):
- Lien ci-dessus +
- Diagramme de séquence par exemple:
http://www.developpez.net/forums/d63...onne-pratique/
Peut-on utiliser une forme de Transfer Object entre IHM et Contrôleur IHM? Et/Ou entre Contrôleur IHM et Contrôleur DAO?
En fait je voudrais savoir si c'est gênant que la classe -(ou même une fabrique
pour cette classe)- du Transfer Object en question (Customer dans leur exemple) soit connue au niveau de l'IHM ou du Contrôleur IHM?
Et plus précisément, avec l'exemple suivant:
Au niveau de l'IHM: on est sur une Fiche de création de User.
La personne qui saisit, renseigne à ce jour: le login, le passw puis valide.
La validation sollicite le Contrôleur IHM qui sait alors qu'il doit venir récupérer
les données User saisies.
LAQUELLE DES 6 SOLUTIONS PRESENTEES ci-dessous VOUS SEMBLE LA PLUS CLEAN ???
LAQUELLE voyez-vous le plus souvent?
LAQUELLE utilisez-vous le plus souvent?
(Ici mon Transfer Object est donc un objet User).
//----------------------------------------------
SOLUTION 1:
-La classe IHM connaît carrément la Classe concrète User.
-La classe contrôleurIHM connaît le type abstrait User.
-->GROS INCONVENIENT: couplage de l'IHM avec 1 type concret du MODELE: type User.
class IHM
{
//...
void actionPerformed(...)
{
if (clickSurValid)
this.controleurIHM.demande_addUser(); //Informe son ControleurIHM de la validation
//...
}
//Renvoie l'intégralité de la saisie sous forme d'objet User.
User getUser()
{
String login=this.widgetLogin.getvalue();
String passw=this.widgetPassw.getvalue();
//L'IHM connaît donc la classe CONCRETE User!!!
User trsf_object=new User(login, passw); //<<<<<<< !!
return(trsf_object);
}
//...
}
class controleurIHM
{
//...
void demande_addUser() //Appelée suite à validation de la fiche User.
{
//Recup. sous forme d'Objet User, du User saisi.
User trsf_object=this.vue.getUser();
//Demande au Contrôleur DAO de créer la fiche pour le User décrit par trsf_object.
this.controleurDAO.insertUser(trsf_object);
}
//...
}
//----------------------------------------------
SOLUTION 2:
-La classe IHM connaît une fabrique concrète de User, et aussi le type User abstrait .
-La classe contrôleurIHM connaît le type abstrait User.
-->GROS INCONVENIENT: couplage de l'IHM avec 1 type concret du MODELE: fabriqUser et 1 type abstrait: User.
class IHM
{
//...
void actionPerformed(...)
{
if (clickSurValid)
this.controleurIHM.demande_addUser(); //Informe son ControleurIHM de la validation
//...
}
//Renvoie l'intégralité de la saisie sous forme d'objet User.
User getUser()
{
String login=this.widgetLogin.getvalue();
String passw=this.widgetPassw.getvalue();
//L'IHM connaît donc une fabrique concrete de User, et le type User abstrait
fabriqUser fabriq=new fabriqUser();
User trsf_object=fabriq.makeInstance(login, passw); //<<<<<< !!
return(trsf_object);
}
//...
}
class controleurIHM
{
//...
void demande_addUser() //Appelée suite à validation de la fiche User.
{
//Recup. sous forme d'Objet User, du User saisi.
User trsf_object=this.vue.getUser();
//Demande au Contrôleur DAO de créer la fiche pour le User décrit par trsf_object.
this.controleurDAO.insertUser(trsf_object);
}
//...
}
//----------------------------------------------
SOLUTION 3:
-La classe IHM connaît le type abstrait de la fabrique de User, et aussi le type User abstrait.
-La classe contrôleurIHM connaît le type User abstrait ET le type concret ou même abstrait de la fabrique de User.
-->GROS INCONVENIENT: couplage de l'IHM avec 2 types abstraits du MODELE: User et fabriqUser.
class IHM
{
//...
void actionPerformed(...)
{
if (clickSurValid)
this.controleurIHM.demande_addUser(); //Informe son ControleurIHM de la validation
//...
}
//Renvoie l'intégralité de la saisie sous forme d'objet User.
User getUser( fabriqUser fabriq ) //<<Reçoit une fabrique de User.
{
String login=this.widgetLogin.getvalue();
String passw=this.widgetPassw.getvalue();
//L'IHM connaît le type abstrait de la fabrique de User, et aussi le type User abstrait.
User trsf_object=fabriq.makeInstance(login, passw); //<<<<<<
return(trsf_object);
}
//...
}
class controleurIHM
{
//...
void demande_addUser() //Appelée suite à validation de la fiche User.
{
//Recup. sous forme d'Objet User, du User saisi.
//On peut imaginer que this.fabriqUser a passée en param. au constructeur du
//contrôleur ou encore a été initialisé par un :
// fabriqUser this.fabriqUser=this.controleurDAO.getFabriqUser();
User trsf_object=this.vue.getUser( this.fabriqUser ); //<<<<<
//Demande au Contrôleur DAO de créer la fiche pour le User décrit par trsf_object.
this.controleurDAO.insertUser(trsf_object);
}
//...
}
//-------------------------------------------
SOLUTION 4:
-La classe IHM ne connaît pas le type User, ni même une fabrique de User.
-La classe contrôleurIHM connaît la classe User concrète.
-INCONVENIENTS:
-->Si on rajoute n infos supplémentaires à saisir (Nom, Prenom,...) alors:
---->Ca fait n méthodes en plus à créer dans la classe IHM.
---->Ca fait n this.vue.getXXX() à faire en plus dans le contrôleur.
---->Donc au moins n risques d'erreurs , d'oublis en plus.
-->GROS INCONVENIENT: couplage du Controleur IHM avec un type concret du MODELE: type User.
class IHM
{
//...
void actionPerformed(...)
{
if (clickSurValid)
this.controleurIHM.demande_addUser(); //Informe son ControleurIHM de la validation
//...
}
String getLogin()
{
return( this.widgetLogin.getvalue() );
}
String getPassw()
{
return( this.widgetPassw.getvalue() );
}
//...
}
class controleurIHM
{
//...
void demande_addUser() //Appelée suite à validation de la fiche User.
{
//Interroge la vue champ de saisie par champ de saisie. <<<<<<<<<
String login=this.vue.getLogin();
String passw=this.vue.getPassw();
//Mise sous forme d'Objet User des infos User saisies.
User trsf_object=new User(login, passw); //<<<<<<<<<<<
//Demande au Contrôleur DAO de créer la fiche pour le User décrit par trsf_object.
this.controleurDAO.insertUser(trsf_object);
}
//...
}
//-------------------------------------------
SOLUTION 5:
-L'IHM ne connaît pas le type User, ni même une fabrique de User.
-La classe contrôleurIHM connaît le type User abstrait ET le type concret ou même abstrait de la fabrique de User.
-INCONVENIENTS:
-->Si on rajoute n infos supplémentaires à saisir (Nom, Prenom,...) alors:
---->Ca fait n méthodes en plus à créer dans la classe IHM.
---->Ca fait n this.vue.getXXX() à faire en plus dans le contrôleur.
---->Donc au moins n risques d'erreurs , d'oublis en plus.
-->Couplage du Controleur IHM avec un type (au mieux) abstrait du MODELE, à savoir: le type fabriqUser.
class IHM
{
//...
void actionPerformed(...)
{
if (clickSurValid)
this.controleurIHM.demande_addUser(); //Informe son ControleurIHM de la validation
//...
}
String getLogin()
{
return( this.widgetLogin.getvalue() );
}
String getPassw()
{
return( this.widgetPassw.getvalue() );
}
//...
}
class controleurIHM
{
//...
void demande_addUser() //Appelée suite à validation de la fiche User.
{
//Interroge la vue champ de saisie par champ de saisie. <<<<<<<<<<<<<<<
String login=this.vue.getLogin();
String passw=this.vue.getPassw();
//Mise sous forme d'Objet User des infos User saisies.
//On peut imaginer que this.fabriqUser a passée en param. au constructeur du
//contrôleur ou encore a été initialisé par un :
// fabriqUser this.fabriqUser=this.controleurDAO.getFabriqUser();
User trsf_object=this.fabriqUser.makeInstance(login, passw); //<<<<
//Demande au Contrôleur DAO de créer la fiche pour le User décrit par trsf_object.
this.controleurDAO.insertUser(trsf_object);
}
//...
}
//-------------------------------------------
SOLUTION 6:
( PAS de Transfer Object dans cette solution ).
-La classe IHM ne connaît pas le type User, ni même une fabrique de User.
-La classe contrôleurIHM ne connaît pas le type User, ni même une fabrique de User.
-INCONVENIENTS:
-->Si on rajoute n infos supplémentaires à saisir (Nom, Prenom,...) alors:
---->Ca fait n méthodes en plus à créer dans la classe IHM.
---->Ca fait n this.vue.getXXX() à faire en plus dans le contrôleur.
---->Donc au moins n risques d'erreurs , d'oublis en plus.
class IHM
{
//...
void actionPerformed(...)
{
if (clickSurValid)
this.controleurIHM.demande_addUser(); //Informe son ControleurIHM de la validation
//...
}
String getLogin()
{
return( this.widgetLogin.getvalue() );
}
String getPassw()
{
return( this.widgetPassw.getvalue() );
}
//...
}
class controleurIHM
{
//...
void demande_addUser() //Appelée suite à validation de la fiche User.
{
//Interroge la vue champ de saisie par champ de saisie. <<<<<<<<<<<<<<<
String login=this.vue.getLogin();
String passw=this.vue.getPassw();
//Demande au Contrôleur DAO de créer la fiche pour le User saisi.
this.controleurDAO.insertUser(login, passw);
}
//...
}
//-------------------------------------
La SOLUTION 6 est celle qui nécessite le moins de couplage, cependant elle n'est pas sans les inconvénients mentionnés. De plus, La signature de la méthode insertUser() du ContrôleurDAO reste du coup dépendante du NOMBRE d'attributs d'un User! (Sans compter qu'il ne faudra alors pas se planter sur l'ordre de transmission de ces paramètres!!), ceci donc du fait que cette solution n'utilise pas de Transfer Object.
Personnellement, je sens bien la SOLUTION 3 car elle n'a pas les inconvénients de la SOLUTION 6 d'une part, et d'un point de vue couplage ça reste du couplage qu'avec du type abstrait (User et fabriqUser). Pour le reste je n'ai pas assez d'expérience du MVC pour pouvoir donner mon avis. Ce qui me gêne malgré tout dans cette SOLUTION 3 c'est que l'IHM
elle-même sache des choses (même abstraites) sur le MODELE... ceci dit l' l'IHM est censée représenter le MODELE alors...?
Et vous,:
LAQUELLE DES 6 SOLUTIONS VOUS SEMBLE LA PLUS CLEAN ???
LAQUELLE voyez-vous le plus souvent?
LAQUELLE utilisez-vous le plus souvent?
MERCI BEAUCOUP de partager votre expérience sur ces points.
MILLE MERCIs pour vos avis et critiques.
Répondre avec citation
.
) dans tes solutions tu mets en évidence que la Vue à une visibilité sur le modèle (dans toutes tes solutions quasiment) hors le principe pilier du MVC c'est la strict séparation entre le modèle et la vue (d'où l'utilisation d'un controleur). 
Envoyé par rp37000
Partager