Discussion :

[dahtah]

Bonjour à tous,
Dans VS2005 j'ai crée une solution comprenant quatre projets : Launcher, Model, Controller, Vue.
Launcher est un projet WinForm.
Model, Controller et Vue sont des bibliothèques (dll).
Vue possède une référence à Controller et Model.
Controller possède une référence à Model. Quant je veux ajouter une référence à Vue, VS me jette en me disant ("L'ajout à ce projet entrainerai une référence circulaire").
Ce n'est pas le cas. Dans Controller je me contenterai de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IAbstractVue mainForm = new MainForm(this, model);

ça n'entraîne pas de référence circulaire, quand je fait tout dans un projet, pas de problème.
Des idées d'où celà peut venir?
Merci

[ZaaN]

Dans ton controller, le fait d'utiliser IAbstractVue génère une reference vers la vue !

Ton MVC est correct :



Tout est parfaitement normal. Vue à une ref sur controller et vice versa --> ref circulaire (la DLL Vue a besoin de Controller pour compiler et vice versa).

La solution est la suivante implementer ton MVC dans le meme composant.

Et je trouve ca logique, car le fait de separer en DLL multiple permetrait d'interchanger facilement sans connaitre l'implementation des DLL. Ce qui semble inutile car pour creer une nouvelle DLL (M,V ou C) il faut connaitre l'interface des autres.

ou alors tu peux mettre les interface à part, mais tu n'as plus la garentie d'avoir des interface a jour --> controlle de version.

Tu m'as suivi ?

[Bluedeep]

En général, les références circulaires sont dues à une mauvaise conception de la répartition des classes entres les bibliothèques (ou plus).

On peut en général le contourner en mettant les interfaces dans une bibliothèque séparée.

[dahtah]

La solution est la suivante implementer ton MVC dans le meme composant.

Et je trouve ca logique, car le fait de separer en DLL multiple permetrait d'interchanger facilement sans connaitre l'implementation des DLL. Ce qui semble inutile car pour creer une nouvelle DLL (M,V ou C) il faut connaitre l'interface des autres.

ou alors tu peux mettre les interface à part, mais tu n'as plus la garentie d'avoir des interface a jour --> controlle de version.

Tu m'as suivi ?

Oui, tu me conseille de tout mettre dans un même projet.

Mais, la séparation des interfaces dans un autre projet ne change pas le problème je pense. Mon interface même séparée dans un autre projet devra référencer ma Vue (Donc controleur référence Vue). Donc toujours référence croisée.

Généralement, pour MVC, vous mettez tout dans le même projet?

[ZaaN]

Oui, tu me conseille de tout mettre dans un même projet.

Mais, la séparation des interfaces dans un autre projet ne change pas le problème je pense. Mon interface même séparée dans un autre projet devra référencer ma Vue (Donc controleur référence Vue). Donc toujours référence croisée.

Généralement, pour MVC, vous mettez tout dans le même projet?

Cela dépend : Le fait de réunir dans un meme projet à l'avantage de pouvoir distribuer facilement ton composant executable, (et donc proteger tes sources). Donc en fonction de la confidentialité du code, des intervenants sur le projet, etc...

J'aborde ici que le coté protection du code, mais plusieurs autrea facteurs entre aussi en compte : l'extensibilité, la modularité, la portabilité, la flexibilité, etc...

[dahtah]

Ce que je privilégie ici, c'est la flexibité et la modularité.
Peux tu m'en dire plus sur :

ou alors tu peux mettre les interface à part, mais tu n'as plus la garentie d'avoir des interface a jour --> controlle de version.

Merci

[SaumonAgile]

Cela dépend : Le fait de réunir dans un meme projet à l'avantage de pouvoir distribuer facilement ton composant executable, (et donc proteger tes sources). Donc en fonction de la confidentialité du code, des intervenants sur le projet, etc...

L'aspect protection du code n'a rien à voir là dedans. Tu peux "protéger les sources" que le composant soit séparé en plusieurs assemblies ou qu'il soit en une seule.

[Nikoui]

Ton MVC est correct :



Tout est parfaitement normal. Vue à une ref sur controller et vice versa --> ref circulaire (la DLL Vue a besoin de Controller pour compiler et vice versa).

Je dis probablement une grosse bêtise, mais je me lance quand même :

pourquoi mettre une référence de Vue vers Controller ? Le Controller a besoin de connaitre la vue, mais la vue "lève des évènements" et donc n'a pas besoin de référence vers le Controller (c'est lui qui s'abonne à la vue, pas la vue qui pointe vers le Controller). Non ?

Edit : Et de la même façon, pourquoi Model doit il référencer la vue ?

[dahtah]

Je dis probablement une grosse bêtise, mais je me lance quand même :

pourquoi mettre une référence de Vue vers Controller ? Le Controller a besoin de connaitre la vue, mais la vue "lève des évènements" et donc n'a pas besoin de référence vers le Controller (c'est lui qui s'abonne à la vue, pas la vue qui pointe vers le Controller). Non ?

Je comprend pas trop ce que tu veux dire. Mais, le controller instancie la vue (donc besoin de référence Vue) et communique avec le model(référence Model).
La Vue s'abonne aux évènements du Model(référence Model), et fait redescendre ses données au controleur (référence Controleur), qui les traite vers Model.

Edit : Et de la même façon, pourquoi Model doit il référencer la vue ?

Model ne référence pas la vue, ni le controller..

[Nikoui]

La Vue [...] fait redescendre ses données au controleur (référence Controleur)

Pour moi dans le MVC la vue lève des évènements. Et le Controller est abonné à ces évènements (donc le controller reference la vue, mais pas besoin de l'inverse).

Model ne référence pas la vue

J'avais cru lire que c'était le cas dans l'implémentation de l'auteur du post, mais effectivment c'est OK sur ce point.

Mais pour moi (et c'est aussi ce que montre le schéma) il n'y a pas de réference circulaire dans le MVC.

[ZaaN]

si tu tiens vraiment à separer dans des projets distincts, tu dois fournir a chaqur projet les reference sur les interfaces necessaire à l'interieure de ce dernier.

Pour assurer que les interfaces entre les differents composants sont a jour, ( dansle cas ou les composant n'evoluerais pas ensemble) tu dois controller toujours la version de l'interface que tu implemente par rapport à celle du composant.

Tres facile avec .Net mais faut le faire quand meme ! Du genre un truc comme ca

_VersionNB est fournir par l'interface distante ( celui qui va utiliser la Dll)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//get version field from version attribute            
Version m_VersionNb = Assembly.GetExecutingAssembly().GetName().Version;
 
//compare version number
int iCompVerResult = m_VersionNb.CompareTo(_VersionNb);
//analyse comparison result
if (iCompVerResult < 0)
{
    //version too old (user want a more young version)
    throw new BadVersionException("Assembly too old : " + typeof(CInterpreter).Assembly.GetName());
}            
else if (iCompVerResult > 0)
{
    //version younger (user use a old version)                
}
else
{
    //same version                
}

[dahtah]

Pour moi dans le MVC la vue lève des évènements. Et le Controller est abonné à ces évènements (donc le controller reference la vue, mais pas besoin de l'inverse).

C'est une implémentation possible de MVC (quant c'est un MVC classique), que je ne pouvais pas utiliser.
En gros soit tu fais :
1 Controller :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

abstractVue.TextChanged += ...

2 Vue :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

controller.SetText(Text);

Pour certaines raisons j'ai du faire la solution 2. Mais même dans la solution 1, tu dois tout de même instancier ta vue dans le controleur (donc référence Vue), avant de pouvoir t'abonner.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IAbstractVue abstractVue = new ConcreteVue(model);

Zaan, merci beaucoup pour ton aide.
Je vais tout mettre dans le même projet, et séparer les couches par des dossiers.