Bonjour,

Je viens du langage C et je galère un peu.
Je voudrais utiliser le design pattern MVC pour éviter de tout pèter si le design de l'IHM ne plait pas au marketing.

Je veux essayer de faire un système multi vues, mais j'ai du mal à voir comment instancier le tout.

Donc mon modèle possède plusieurs classes, ainsi que le controleur. J'ai choisi de passer par les interfaces (pas par les événéments) pour communiquer.

Pour que le modèle soit unique pour toutes les vues, je pense qu'il faut un(des) singleton(s).

Ai-je pris la bonne méthode ? : interfaces.

Je pense faire une dll pour la définition des interfaces, une autre pour le modèle et une dernière pour le controleur, et l'exe pour la vue.
Dans le 'main' de l'exe, je compte instancier le modèle et la vue. Le contrôleur étant instancié par le modèle.
Si le modèle est un singleton, est ce tous les exe vont faire référence au même modèle ?

Vais-je droit dans le mur avec une architecture comme celle-ci ?

Merci.

PS : je sais que c'est difficile de répondre sans connaitre le projet. Les exemples trouvés sur le Net m'ont appris à comprendre les principe de MVC.

faire des singletons tempechera juste d'instancier plusieurs fois.....
de toutes facons, C# = références....
evidemment il y a des cas ou tu travaille sur des copies, mais dans la plupart des cas, tu passe par référence. alors pas la peine de te poser de questions, ton modele sera bien le meme pour tout le monde pour peu que tu code tout proprement....
si tu veux savoir dans quels cas des copies temporaires sont crées, la MSDN référence les rares cas ou ceci est fait....essaie une recherche sur "get", tu devrais avoir le lien vers la page a priori (car le "get" renvoie une copie de l'objet).

au niveau de larchitecture, le MVC est a mon sens adapté a tout type de projet,  et permet de bien tout poser a plat....une architecture comme celle ci est sympa pour des petits projets histoire de bien s'organiser, et devient un vrai bonheur pour des projets de moyenne/grosse envergure....y'a vraiment aucune raison que tu aille droit dans le mur avec un telle architecture....

séparer les composants dans des dll, tres bonne idée (j'ai facilement tendance a procéder ainsi lorsque j'utilise le MVC).

dans le main, jaurais plutot lancé instancié la vue tout bêtement, vue qui instancie le controlleur, et controlleur qui instancie le modèle. Apres ca depend aussi un peu de ton appli.

enfin, si tu as beaucoup de vues, plusieurs solutions pour une bonne clarté :
-une interface de controlleur par vue, et un controlleur qui implémente toutes les interfaces
-un controlleur par vue, et un controlleur global qui gere les différents gérants (plus ou moins la meme chose que les interfaces, mais code plus séparé dans des fichiers, on évite d'avoir 452 directives #region pour bien tout séparer...j'ai une préférence pour cette solution a cause de ca)

j'espere t'avoir aidé et avoir répondu à la plupart de tes questions. Au pire reposte, je viendrais surement rejetter un oeil ;)

PS : attention, le MVC version web est assez mal adapté au MVC version applis standalone....j'espere que tu as fait la différence, sinon tu vas te trouver devant qqs problématiques par moments.....de plus, n'hesite pas a parfois prendre quelques libértés avec le pattern....pas trop non plus pour garder une cohésion, etc....mais dans certains cas, il vaux mieux mettre le pattern un peu de coté et ne pas se borner a le respecter au maximum

Merci beaucoup pour toutes ces infos.

En réalité mon appli est une "TreeView", ou plutot une arborescence et chaque niveau de noeuds représente un type d'objet.

C'est un autre module qui va créer les objets, je pensais donc faire comme ceci :
- créer l'objet (modèle)
- l'objet crée un controleur (pour détecter des modification)
- la fonction qui a créé l'objet envoie (par un moyen ou un autre : le controleur global, je pense) l'objet à la vue pour créer "l'objet graphique" (qui pour le moment serait un noeud de treeview)
- Ma classe dérivée de TreeNode s'abonne au controleur de l'objet


P.S. : j'ai voulu faire un truc propre avec des namespaces différents pour le M, V, C et les Interfaces, mais ça deconne avec les interfaces, pour le moment, j'ai remis un namespace unique et je reviendrai sur ce pb plus tard. Pour le moment, c'est plutot une appli test (avec 'reuse' important) pour appréhender MVC.