Discussion :

[nytmare]

Bonjour,
avec le pattern MVC en réduit le couplage entre les trois couche, de telle sorte que l'interface graphique n'agisse pas vraiment sur les données..ok!

mais il faut bien avoire un formatage de donnée et envoie de formulaire, alors si j'ai bien compris l'interface manipule en faite les objets à travers leur interfaces. donc se qui nous mene a avoire une classe interface pour chaqu'un de nos objet. C'EST BIEN CA ???????
Mais j'ai vue des projets implémentant le pattern MVC,controlleur,observer
sans utiliser d'interface..enfin je n'est vue que les diagramme de séquence et de classe.....
Esqu'on utlise les interafce, sans les mentionnées dans nos diagramme par soucis de place ???(chaque classe a une interface)

Merci


ps:y'a bien des diagrammes de classe avec des interface technique.
ps:l'interface UI instancie un Iclient,le ramplis et l'envoie au controller,ceci n'existe pas dans les diag de séquence.?.

[viena]

normalement, l'interface graphique manipule des objets "bean", on fait rarement des interfaces avec ce type d'objet.
Par contre, par exemple, pour l'acces en base, on imagine qu'on ne sais pas si on va utiliser oracle ou postgres, jdbc ou du mapping... donc, la, on utilise une interface, qui est appelée par l'appli pour avoir acces aux donnees en base (ou dans autre systeme de stockage) et ce, sans savoir ce qui se passe derriere.
Ce degres d''abstraction permet de separer fortement les differentes logiques.
C'est egalement utiliser pour les classes metier...

[ego]

En fait, le modèle MVC ne dit pas que le V manipule le M via des interfaces. Bien sûr que le V connait le M dans MVC. MVC sert juste à dire que le V n'appelle pas directement le M et inversement; tout passe par le C.
La notion d'interface c'est autre chose comme l'a expliqué mon prédécesseur.

[Invité]

Bien sûr que le V connait le M dans MVC.

je ne suis pas d'accord. dans mes programmes en MVC, aucune instance d'un Modele n'est declaré dans une Vue, et vice-versa. la Vue affiche des données, mais elle ne sait pas d'où le Controleur a amené ces données.

pour la question de nytmare, perso je fais toujours figurer les Vues dans mes diagrammes de classes niveau conceptuel. pareil pour les diagrammes de sequences, les Vues doivent etre les instances les plus proches de l'utilisateur.

autre chose : utiliser plutot le terme de Vue pour parler d'une classe qui affiche les donnees dans l'architecture MVC. car le terme "interface" peut avoir une signification dfferente, comme l'a expliqué viena.

[ego]

Quand je dis V connait M je dis simplement que V connait la structure des objets à afficher, des JavaBeans par exemple en Java.
Je n'ai pas dis que V savait comment C va rechercher M ou sait où est M !!! Ensuite, l'utilisation d'objets comme les ValueObject par exemple et qui pourrait laisser dire que V ne connait pas M est en fait un autre problème. Dans MVC, V connait M, sa structure !!!!!

[alex00]

J'ai l'impression qu'il y a parfois confusion entre MVC et BCE (boundary, Control, Entity).

MVC : http://www.enode.com/x/markup/tutorial/mvc.html
Vues et modèles se connaissent.
Pour limiter le couplage entre Model et Vue dans les langages fortement typés, on peut utiliser un Observer dont héritent les vues.

Observer : http://www.research.umbc.edu/~tarr/dp/lectures/Observer.pdf
(je n'ai pas lu la discussion qui suit - j'ai seulement aperçu l'interface java Observable - qu'il ne me semble pas opportun d'utiliser)

BCE :
les classes frontières (B) et entités ne se connaissent pas.
http://deptinfo.cnam.fr/Enseignement/CycleProbatoire/3I/MSI/Partie3/P37.pdf
page 3.

Remarque :
BCE colle à la réalisation des cas d'utilisations (méthode de I. Jacobson)
MVC colle aux architectures java (J2EE, Struts, ...)

Quant à l'utilisation des interfaces (classes abstraites), les patterns Observer et Facade en donnent de bons exemple : celui de limiter le couplage.

[nytmare]

Effectivement MVC, BCE il faut faire la difference..
Cependant je travail avec .NET et des winform (MVC ou pas je sais si ca se dit dans ce cas).
disant que je travaille avec du mapping
j'ai mes objets pesistant A ,B qui implemente une interface IA ,IB
interface IA
{
string name {set;get}
string cool {set;get}
IB b;
}
au niveau Controller un méthode
public IA findAByName(....)
ma méthode retourne l'interface de mon objet
j'ai une abstractfactory et je projette de rajouter un observer !!pour les MAJ
pour la facade j'en vois pas l'utilité l'abstract factory joue bien se role
au niveau interface
je dois remplire un formulaire associé à A
IA a=Factory.Controller.findAByName(...);
textbox1.text=a.name;
....
....
//c'est ce que je voulais dire par manipuler les objets par leur interfaces

cette méthodologie est elle saine ?
quesqu'il ya lieu de faire sinon ?
dans le diagramme de séquence que dois je faire ?

Dans mon analyse j'ai utiliser les stérétypes BCE
un diagramme de classe métier n'implique que les objet métiers,quand utiliser un diagramme de classe avec toute les classe issus des interaction BCE ?

Enfin de toute façon je dois sérilalisé mes objets --> pattern DTO j'effetue une copie de l'objet,et la peut etre que j'aurais un genre de bean (set,get) comme vous ditent.

MERCI

[ego]

Pas de soucis avec ta conception sauf que comme je l'ai mentionné, l'usage d'interfaces n'a rien à voir avec MVC. Connaitre un objet par son interface ou non dans le cas du V de MVC n'est qu'une particularité offerte par les langages comme Java ou C#. Ceci dit, c'est une bonne habitude que d'utiliser des interfaces.

Pour la distinction entre BCE et MVC, si on remonte à l'origine du MVC dans Smalltalk, le MVC ne doit pas seulement être associé à l'interface graphique. Et dans Smalltalk BCE ~= MVC. Mais bon, il est vrai que dans le monde Java (.Net je connais moins), on associe MVC à la couche IHM.
On a donc souvent l'empilement VCMBCE ou VCMCE (enfin bref, je me comprend ! :-) )

[alex00]

dans le diagramme de séquence que dois je faire ?

Si ton diagramme de séquence présente le point de vue IHM, alors ne présente que les interfaces.
Si ton diagramme de séquence présente le point de vue métier, alors présente les objets métiers qui héritent des interfaces : ne complique pas en ajoutant les interfaces (qui prennent pour valeur les objet métier sur retour d'appel au contrôleur).

Remarque : si tu veux avoir des objets métiers indépendant de leur différentes représentations, ne pollue pas les objets métier ni avec l'IHM (ce que tu fais déjà) ni avec la persistance.
Pour être le plus propre possible : les objets de transfert de données contiennent des valeurs issues des objets métiers ; les classes DTO et métier ne sont pas liées (pas d'héritage), un builder est capable de créer/modifier des objets métier en DTO (et dans l'autre sens).
Mais ça a un coût (probablement négligeable en perf, pas en dev et test).

[nytmare]

je comprend
donc je me trompe pas, au niveau UI il faut bien manipuler quelque chose dans mon cas manipuler les interface comme je le fait c'est pas un antipattern (ou mal sain)?

Builder ????? euh.. vous vouler dire un Assembler, ne me faite pas espérer qu'il ya un builder qui crée des dto auto de mes classe ca serai trop beau, care effectivement je galere et faire du generique ne résous pas le probleme.

Remarque : si tu veux avoir des objets métiers indépendant de leur différentes représentations, ne pollue pas les objets métier ni avec l'IHM (ce que tu fais déjà) ni avec la persistance.

quesque je fait ?

ego

On a donc souvent l'empilement VCMBCE ou VCMCE (enfin bref, je me comprend ! )

Struts en est un bonne exemple je trouve

MERCI

[viena]

Citation:
Remarque : si tu veux avoir des objets métiers indépendant de leur différentes représentations, ne pollue pas les objets métier ni avec l'IHM (ce que tu fais déjà) ni avec la persistance.

quesque je fait ?

En fait, il ne faut pas qu'il y ait de la persistance et de l'IHM dans tes metier.
cad que tu as des classes qui s'occupe de l'acces en base, des interface qui les defini. des classes metier qui utilise les interfaces pre citees pour recup les info et des classes pour l'IHM (actions si tu utilises struts). Tu peux faire, si c'est necessaire (la conception le dira), des interface pour tes classes metier pour dialoguer avec les classes de persistance et les actions.

[alex00]

c'est pas un antipattern (ou mal sain)?

Comme l'a dit vienna, c'est tout bon.

car effectivement je galère et faire du générique ne résous pas le probleme.

Comme tu le remarques, c'est lourd à faire à la main. C'est là que tu forges ton expérience : tu ne t'embêteras plus sur un petit projet. Mais sur un gros, l'avantage de cette conception, c'est que dans ta couche métier, tu auras suffisamment à faire avec le métier et tu ne seras pas pollué par la technique.

[nytmare]

ok ,
franchement entre tout ca, mes objet metiers ce pert.
dans ma couche de controle que j'appele BLL (buisness logique layer) en effet toute logique s'y trouve.du coupe tout mes objet (metier) sont le fruit de ma couche de mapping, d'ailleur mon outils de mapping les generes....... donc bizarrement je me retrouve juste avec des méthode CRUD, et encore je ne les utilise que indirecement par exemple pour crée A j'ai une méthode dans la couche BLL : Factory.Manage.createnewA(....);
y'a des choses qu'en survole telement qu'en oublie meme l'utilité.
j'ai dus lire quelque part, que les 5 couche remplace en faite les objet metier et les fractionne en mapping entreprise et application, c'est ce qui explique peut etre la situation..je me comprend comme dit ego

enfin ce qui m'interresser en lancant ce thread c'est juste si l'utilisation des interface objets en niveau de l'UI pour les manipuler été sain
MERCI de vos eclaircicement

ps: si quelqu'un a le temps de lire mes note (diag) ca serai génial

[ego]

envois tes diagrammes via un MP si tu veux