Discussion :

[tiboo]

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

[M�dinoc]

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...

[tiboo]

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...

[M�dinoc]

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...

[zais_ethael]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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.

[tiboo]

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?

[zais_ethael]

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.