Problème conception MVC

bonjour,

J'ai une question de conception en c++. Je débute en programmation objet et j'ai conçu une application graphique basée sur une boite de dialogue.

Pour simplifier et donner un exemple concret, un utilisateur choisit le titre d'un ouvrage, l'application se connecte à une base de donnée et récupère les informations de l'ouvrage(année, auteur,...)

Pour réaliser cela, j'ai deux classes principales, une permettant de gérer les bases de données, d'effectuer des requêtes et une autre représentant l'ouvrage et ses attributs. J'aimerai utiliser le pattern Modèle-Vue-Contrôleur mais j'avoue ne pas savoir comment formaliser la chose :

- je vois bien ma vue (ma boite de dialogue et les contrôles s'y rapportant) et les méthodes associées (OnOk,....)
- ma classe contrôleur : à part une méthode pour avertir le modèle de se mettre à jour, aucune idée pour les membres
- le modèle : ma classe ouvrage(dont les attributs seraient les info de l'ouvrage et les méthodes seraient les getter/setter ainsi qu'une methode avertissant a vue de se mettre à jour)

Je ne sais pas ou mettre ma classe base de donnée, comment l'agencer dans ce diagramme.

Je galère pas mal. Qqun pourrait-il me conseiller, m'aider, me donner un exemple?

Merci:roll:

Typiquement, on fusionne le contrôleur avec autre chose.

Le framework Document/Vue de MFC par exemple, fait du document son propre contrôleur, et les vues appellent des méthodes du document...

ok, prenons alors mon exemple,

je renseigne le nom de l'ouvrage qui m'intéresse dans ma boite de dialogue :

- je dois aller charger les paramètres de la base de donnée (située dans un fichier ini(car il y a plusieurs bases dans mon cas selon les ouvrages)
- ouvrir la connection
- construire ma requête grâce a des info du fichier ini toujours relatives à l'ouvrage
- exécuter la requête
- analyser ma requête
- mettre à jour les champs de l'objet ouvrage
- en fonction de ses champs, je dois réaliser tout une série d'opérations connexes comme me reconnecter à une autre base, aller chercher un fichier....


ceci fonctionne très bien quand j'enchaine tout mais cela n'est pas du tout maintenable(trop de ligne) et le code mélange la vue avec le document ce qui rend l'application non maintenable.

Je me perd totalement car j'ai l'impression que je vais avoir une classe "vue" dont les méthodes vont appeler les méthodes de la classe contrôleur(via un objet) qui va lui même appeler les méthode mon objet "ouvrage". les classes vue et contrôleur vont être complètement vides alors que la classe "ouvrage" va contenir tout l'enchainement des actions... Or je voudrais que ma classe "ouvrage" puisse être réutilisable et ne pas inclure des traitements spécifiques

la classe 'contrôleur' doit-il effectuer ma requête sur ma base de donnée? Ma classe ouvrage doit-elle contenir uniquement des getter/setter ou dois je gérer la connection à la base de donnée?

je tourne en rond depuis plusieurs jours avec ça...

Pour la requête sur la base de données, je verrais plutôt une classe "ChargeurOuvrage" qui s'en chargerait...

Et je pense que le rôle revient au contrôleur de passer au modèle un pointeur vers cette classe de chargement...

Salut.
Tu ne devrais pas trop t'inquiéter pout ton controlleur. En fait, celui-ci ne sert vraiment que lorsqu'on a une vue dénué d'intelligence (typiquement: une page html) et ne sert qu'à formater et controller les données. Dans une applic desktop tu peux considérer que la vue et le controlleur sont la même chose, parceque'il est plus utile et efficace de faire toutes ces vérifications dans les composants graphiques eux-même (pour afficher facilement les messages d'erreur par exemple).
Pour ton modèle, c'est ce qu'on appelle la couche métier dans le modèle 3-tier (qu'il te serait plus utile de connaitre que le modèle MVC dans le cadre d'une applic desktop soit dit en passant). Il n'y a pas vraiment de règle, il faut juste se dire que c'est une couche dénuée de tout aspect graphique, on devrait donc pouvoir mettre au point toute sorte d'interface par dessus (console, gui, web,...). Il faut aussi que cette couche soit assez abstraite, sans réfèrence à des objets de la bibliothèque que tu utilises pour te connecter à ta base de données entre autres (mais bon, pour une petite applic tu peux quand même te permettre de faire passer des informations pour qu'elle puisse se connecter à la base de données).
Voici à quoi pourrait ressembler ton modèle/ta couche métier dans le cas qui te préoccupe:

Code:

---

1 2 3 4 5 6

class ouvragebusiness { list<ouvrage> getallouvrage(); ouvrage findouvrage(...); void addouvrage(ouvrage); ... }

---

Pas de biblio d'interface, pas de biblio de bd, et non plus forcément de rapport direct avec les tables de ta bd (ça c'est le role de la couche données, mais je te laisse potasser le modèle 3-tiers et l'archetecture DAO pour comprendre).
Et pour ce qui est de ta vue/ton controlleur (même chose dans ce cas), franchement, il est rare d'utiliser un pattern précis. Contente toi d'utiliser un maximum les bonnes règles de programmation que tu connais pour avoir le maximum de réutilisabilité. En général ce que je fais c'est stocker quelques informations sur l'état en cours du programme (du genre "en attente d'entrée de l'utilisateur", "en attente de reception des données",...) puis dés que je dois mettre à jour les données, je fais tout passer par une seule et même fonction qui met à jour chaque composant affiché en fonction de l'état, sans jamais me préoccuper de l'état précédent.

bien vu zais_ethael, je me suis renseigné sur cette architecture. En effet, cela a l'air de convenir à ce que je souhaite.

si j'ai bien suivi le principe, je vais crée une classe DataAccess qui va s'aoccuper de traiter de mes données (acces base de donnée, mise à jour info). J'aurai ainsi

classe 'vue' <=> classe DataAccess <=> classe 'ouvrage', classe 'DBAccess'

ma classe 'Vue' va effectuer les controle de donnée entrée par l'utilisateur, va appeler la classe DataAcces pour ui signaler qu'elle peut mettre à jour els données,
ma classe DataAccess va faire traiter les données grace aux methode des classe ouvrage et DBAccess et va informer la vue qu'elle peut se mettre à jour.
mes classes DBAccess, ouvrage vont stockées les données et fournir des methode permettant d'y acceder et de les mettre à jour.

qu'en pensez vous?

C'est pas mal. Juste quelques petites précisions:
- Je ne sais pas si c'est le cas de ta classe ouvrage, mais il est nécessaire de stocker les données dans un "value object", un objet qui a pour seul but de contenir des données, et qui donc soit totalement indépendant de l'interface graphique, de la bd, ou de tous le reste de l'application de manière générale (sauf éventuellement d'autres value objects).
- ta classe DBAccess semble être une sorte de couche données. Si c'est le cas, rappelle toi bien que le but de cette couche est l'indépendance avec la base de données, pour que la couche métier puisse aussi bien utiliser une bd fichier, mysql, oracle,... sans devoir être modifiée d'un poil. Si ce but n'est pas respecté, alors la couche data est inutile et peut aussi bien être laissée de coté. Or il se trouve que pour cela, tu ne peux te contenter de faire du C++ "à la papa", il faut communiquer via des interfaces pour tout faire passer par du polymorphisme objet. Va jeter un coup d'oeil à l'architecture DAO (data access object) pour en savoir plus.