Discussion :

[jeremm]

Bonjour,

J’essaye d’implémenter le pattern MVC en C#.
Après plusieurs lectures j’ai créé mes 3 projets (Control, Model, et View = GUI)



Pour apprendre j’ai fait : une WinForm du GUI contient un DataGridView, qui est censé afficher et rafraichir les données qui proviennent d’une base de données SQLite. J’ai codé les opérations connect/deconnect/insert/update/delete propre à la base SQLite dans le projet Model (Database.cs).
Mais maintenant, je suis bloqué : dans quelle partie dois-je lancer la connexion à la base ? Comment est-ce que la form va-t-elle se rafraichir dès que ma base sql est modifiée ? J’ai lu que c’était le Model qui déclenchait la mise à jour du GUI. Comment faire cela ?

Merci bcp.

[giova_fr]

Personnellement, je trouve que le modele View Presenter est amplement suffisant. Ceux qui veulent me contredire sont les bienvenus.

Ton viewer doit exposer des methodes de Rafraichissement :
OnConnected()
OnAnswer(object datas);
etc...
Pour que le présenter puisse lui ordonner de modififer son affichage à chaque evenements.

Ton présenteur lui s'abonne aux evenements de ta base, qu'il relaye au viewer en ne lui donnant que les infos relatives à l'affichage.

[jeremm]

Salut,
Merci pour ta réponse.

J'ai avancé un peu (finalement). En fait l'utilise le MVC car sur la base décrite précédemment je vais ajouter pas mal de chose, et à force ca sera plus souple à maintenir.
Quel est l'avantage du MVP par rapport au MVC ?

J'ai une question plus précise désormais :
Une fois que le Modèle a modifié la base de données, il envoie un event au Controller pour lui signaler de mettre à jour la listview Winform.
Mon problème est : comment, depuis mon Controller, je peux interagir avec ma listview ? En gros j'ai ma fonction Form1.UpdateListViewData() qui doit etre appelé depuis ma classe Controller.cs, mais je sais pas comment faire ?

Merci !


edit: mon nouveau model :

[giova_fr]

je ne connais pas le pattern avec le controller, mais quelque chose me choque malgres tout :

Pourquoi ta classe controlleur est dans ta dll UI?
On dirait que ca casse tout l'interret de la chose : pouvoir changer d'interface graphique sans probleme de dépendance.

Car aujourd'hui c'est une windowsForm, demain ca sera peut etre une page web, que deviendra alors ton controleur?

Un petit tuto du site qui peut etre te fera voir la chose sous un autre angle :

http://jab.developpez.com/tutoriels/dotnet/mvppattern/

C'est d'ailleur par ce tuto que j'ai appris le pattern, merci à son auteur au passage.

[jeremm]

Pourquoi ta classe controlleur est dans ta dll UI?

En fait je voulais 'rapprocher' le Controller de l'UI, afin de pouvoir accéder à ma winform.. en vain !

Je suis bloqué quoi

Je vais regarder ton site merci. Mais le problème sera toujours d'accéder à la Form en cours depuis une autre classe pour rafraichir les infos..

[giova_fr]

donc mes craintes etaient justifiés.

C'est justement tout l'interret du pattern que de casser la dépendance.

Ton controleur ne doit en aucun cas savoir comment fonctionne ta form, tout ce qu'il doit connaitre, c'est quelques methodes publiques pour dire à ta form de faire telle ou telle action visuelle.

Et inversement, ta form ne doit pas savoir ce que fait Controleur, tout ce qu'elle doit connaitre c'est quelques methodes pour lui dire que l'utilisateur a cliqué sur tel ou tel bouton.

Tout ceci se fait normalement par le biais d'interfaces :

MesInterfaces.dll :
IControler
IViewer

Controleur.dll:
Controleur implémentant IControler

GUI.dll:
Viewer implémentant IViewer et prennant un IControler comme argument dans son constructeur pour pouvoir parler "à l'aveugle" au controleur.