Discussion :

[Mozofeuk]

Bonjour à tous,

Je suis un peu nouveau sur C++ et Qt et on m'a demandé de ré-architecturer une appli qui devenait une usine à gaz.

J'ai donc décidé d'utiliser MVC. Notre appli permet de dessiner différentes info sur des photo (pour faire simple). Donc en gros j'aurais mes Widget qui ferai office de vue/contrôleur car j'ai vu en fait que Qt se basait plutôt sur une architecture vue-model. Mon model étant constitué d'une classe d'accès au données permettant à mes Widget d'afficher les données.

Comme mon model doit pouvoir être utiliser par tout mes Widget je me pause la question suivante :

C'est quoi le mieux pour mon model, une classe Singleton, une classe avec des méthode statiques ?

Cordialement MoZo

[gbdivers]

Bonjour Mozofeuk

C'est quoi le mieux pour mon model, une classe Singleton, une classe avec des méthode statiques ?

Sans plus d'information, je dirais aucun des 2

Ce n'est pas réellement un problème Qt mais de conception en général : pour beaucoup de raisons (cf les nombreux messages sur le forum C++ sur le sujet), l'utilisation des variables globales (qu'elles soient sous forme de variable globale, de singleton ou de static) est à éviter. En gros, si tu n'as pas une raison bien spécifique de les utiliser, ne les utilisent pas.
Dans ton cas, tu peux probablement passer ta classe d'accès aux données comme paramètre à ta classe d'affichage (en utilisant les singaux/slots si nécessaire pour le découplage des classes)

car j'ai vu en fait que Qt se basait plutôt sur une architecture vue-model

Non, pas vraiement. Qt propose (en autre) des classes facilitant l'implémentation du MVC (les systèmes QGraphicsScene+QGraphicsView ou les QAbstractItemModel+QAbstractItemView) mais ce n'est pas une obligation.
Tu peux en particulier (et c'est peut être ton cas) utiliser directement des QWidget (et dérivés) et les positionner avec des QLayout (et dérivés).

Pour aider plus sur les choix architecturaux, il nous faudra plus de détails sur ce que tu veux faire.

Bon courage

[Mozofeuk]

Merci de ta réponse gbdivers,

J'ai mis en parallèle un autre post dans la section design pattern où j'essaye de préciser plus de détail justement :

http://www.developpez.net/forums/d10...attern-mvc-qt/

Pour toi l'utilisation d'un singleton ou de méthodes statiques est le plus souvent à éviter ? Je pensais que de n'avoir qu'un seul et unique objet représentant ma connexion à la base de données et accessible globalement était la solution la plus propre Le mieux serait donc une classe banal ou j'instancie une nouvelle connexion pour chaque widget ?


En tous cas merci pour ton aide

[gbdivers]

Pour toi l'utilisation d'un singleton ou de méthodes statiques est le plus souvent à éviter ?

Oui (pour les arguments, faire une recherche sur le forum C++)

Je pensais que de n'avoir qu'un seul et unique objet représentant ma connexion à la base de données ...

Oui

... et accessible globalement était la solution la plus propre

Le mieux serait donc une classe banal ou j'instancie une nouvelle connexion pour chaque widget ?

Non plus

Détaillons un peu maintenant :
- Chaque widget n'a pas besoin d'avoir une dépendance à tes données : juste tes widgets qui accèdent à tes données (donc pas les boutons, les menus, etc.)
- pour éviter justement de devoir recréer une connexion pour chaque widget (ce qui est relativement peu performant), on crée un seul objet qui manipule cette connexion et qui fournit les données aux différents widgets : c'est le modèle (les widgets étant les vues)
on a donc la structure suivante (en terme de dépendance) : données <-> modèle <-> vues.
- il suffit donc de passer les objets en paramètre (donc pas besoin de les rendre globaux) :

Code :

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

1
2
3
4
class Data {};
class Model { void setData(Data* d); };
class View1 { void setModel(Model* m); };
class View2 { void setModel(Model* m); };

- si tu utilise QAbstractItemModel et QAbstractItemView, tu as déjà un certain nombre de modèle "standard" (table, liste, arbre, table SQL, etc.) et de vues (liste, tableau, arbre, etc.). Tu as juste à définir les fonctions d'accès aux données dans le modèle

(PS : au fait, c'est Qt et non QT )

[Mozofeuk]

Ok, alors si je comprend bien, la classe data comprendra ma méthode permettant d'instancier une connexion et mes méthode d'accès aux données genre

Code :

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

1
2
3
4
5
6
7
class Data{
 
Data(Qstring connectionString);
 
GetCustomers();
GetCustomersById();
}

et ma classe Model sera celle qui instancie mon objet data, appelle les méthodes comme GetCustomers et les transforme en Model utilisable par mes vues c'est ça ?

si tu utilise QAbstractItemModel et QAbstractItemView, tu as déjà un certain nombre de modèle "standard" (table, liste, arbre, table SQL, etc.) et de vues (liste, tableau, arbre, etc.). Tu as juste à définir les fonctions d'accès aux données dans le modèle

J'ai vu un peu tout ça et j'ai commencé à jouer avec, après je devrai surement me créer mes propres models/vues afin de pouvoir répondre à tous nos besoins (je pense au dessin sur nos images).

(PS : au fait, c'est Qt et non QT )

Je retiendrais maintenant

Encore merci de ton aide !!

[gbdivers]

et ma classe Model sera celle qui instancie mon objet data, appelle les méthodes comme GetCustomers et les transforme en Model utilisable par mes vues c'est ça ?

Tu peux faire comme ça : dans ce cas, tu "caches" ta classe à "l'utilisateur" de ta classe modèle (càd la classe qui utilise ta classe modèle) ; l'utilisateur manipule simplement un objet "modèle manipulant une connexion".

L’inconvénient est que tu utilises dans ce cas un modèle spécifique : si tu veux changer la type de données manipulées, tu devras modifier le modèle (en considérant toujours que tu travailles à partir d'une classe dérivées de QAbstractItemModel, pour que tous tes modèles soient compatibles avec les vues de Qt existantes et futures) ; c'est ce que fait Qt par exemple pour les tables SQL avec QSqlTableModel.


Pour commencer, je partirais de la méthode la plus simple :
- tu pars de QStandardItemModel, qui est un modèle standard. Tu appelles simplement dans le constructeur de ta classe dérivées une fonction remplissant ton modèle avec les données lues depuis la connexion (ou dans une fonction setDatabase()) : tu crées simplement un QStandardItem pour chaque données (du texte, une image, etc. stocké dans un QVariant) que tu ajoutes dans le modèle avec appendRow().
L'avantage de QStandardItemModel est que ce n'est pas une classe abstraite comme les autres modèles : tu peux l'utiliser directement. Par contre, il est optimiser pour être polyvalent et pas forcement performant (mais ce n'est pas grave dans un premier temps, il faut que ça marche et ensuite seulement on optimise que ce qui doit l'être)
A ce niveau, tu peux déjà utiliser ton modèle avec les vues standards de Qt (QTableView, QTreeView, QListView, etc.)

- pour tes données spécifiques, qui ne sont pas affiché comme tu veux dans les vues standards, tu crées des QStyledItemDelegate (pour l'affichage Qt:isplayRole et Qt:ecorationRole ou l'édition Qt::EditRole) (les images peuvent être affichées avec Qt:ecorationRole)

- comme charger les données en 1 seule fois n'est pas efficace, tu modifies ensuite ton QStandardItemModel pour le transformer en QAbstractItemModel (ou mieux en QAbstractTableModel ou QAbstractListModel en fonction des besoins) en gérant toi même la fonction data() pour ajouter une politique de gestion des ressources (par exemple conserver que les données affichées et lire les données lors d'une demande d'affichage dans un thread séparé pour ne pas ralentir l'IHM ; mettre en cache les miniatures des images ; anticiper le chargement de certaine image ; etc. cf la série d'articles sur Qt Graphics et performances)

- créer ensuite tes propres vues si besoin

L'avantage de cette méthode est que tu as un résultat visible après chaque étape. Les étapes suivantes ne permettent que d'ajouter des fonctionnalités ou d'améliorer le rendu. Et c'est agréable, quand tu travailles avec du code existant, de pouvoir voir que "ça marche" à chaque étape.