Réponse courte
Le MVC de Qt ne s'applique qu'à une structure de données . Lorsqu'on parle d'un MVC application vous ne devez pas penser à QAbstractItemModel ou QListView .
Si vous voulez une architecture MVC pour l'ensemble de votre programme, Qt ne dispose pas d'un cadre modèle/vue aussi "énorme". Mais pour chaque liste/arbre de données de votre programme, vous pouvez utiliser l'approche MVC de Qt, qui dispose en effet d'un module contrôleur dans son champ de vision. Le site données est à l'intérieur ou à l'extérieur du modèle ; cela dépend du type de modèle que vous utilisez (sous-classe de modèle propre : probablement à l'intérieur du modèle ; par exemple, QSqlTableModel : à l'extérieur (mais peut-être mis en cache à l'intérieur) du modèle). Pour assembler vos modèles et vos vues, utilisez des classes propres qui implémentent ensuite la fonction logique d'entreprise .
Réponse longue
L'approche modèle/vue et la terminologie de Qt :
Qt fournit de simples vues pour leurs modèles. Ils disposent d'un contrôleur intégré : la sélection, l'édition et le déplacement d'éléments sont ce que, dans la plupart des cas, un contrôleur "contrôle". C'est-à-dire qu'il interprète les entrées de l'utilisateur (clics et déplacements de la souris) et donne les commandes appropriées au modèle.
Qt modèles sont en effet des modèles ayant des données sous-jacentes. Les modèles abstraits ne contiennent bien sûr pas de données, puisque Qt ne sait pas comment les stocker. Mais vous étendre un QAbstractItemModel à vos besoins en ajoutant vos conteneurs de données à la sous-classe et en faisant en sorte que l'interface du modèle accède à vos données. Donc en fait, et je suppose que vous n'aimez pas ça, le problème est que vous Vous devez programmer le modèle, c'est-à-dire la façon dont les données sont accédées et modifiées dans votre structure de données.
Dans la terminologie MVC, le modèle contient à la fois le données et le logique . Dans Qt, c'est à vous de décider si vous incluez ou non une partie de votre logique commerciale dans votre modèle ou si vous la placez à l'extérieur, en tant que "vue" à part entière. Ce n'est même pas clair ce que l'on entend par logique : Sélectionner, renommer et déplacer des éléments ? => déjà implémenté. Faire des calculs avec eux ? => à l'extérieur ou à l'intérieur de la sous-classe du modèle. Stocker ou charger des données à partir d'un fichier ou vers un fichier ? => mettre à l'intérieur de la sous-classe modèle.
Mon opinion personnelle :
Il est très difficile de fournir un bon et système MV(C) générique à un programmeur. Parce que dans la plupart des cas, les modèles sont simples (par exemple, uniquement des listes de chaînes), Qt fournit également un QStringListModel prêt à l'emploi. Mais si vos données sont plus complexes que des chaînes de caractères, c'est à vous de voir comment vous voulez représenter les données via l'interface modèle/vue de Qt. Si vous avez, par exemple, une structure avec 3 champs (disons des personnes avec un nom, un âge et un sexe), vous pouvez affecter les 3 champs à 3 colonnes différentes ou à 3 rôles différents. Je n'aime pas les deux approches.
Je pense que le cadre modèle/vue de Qt n'est utile que lorsque vous voulez afficher structures de données simples . Il devient difficile à manipuler si les données sont de type types personnalisés ou structuré non pas en arbre ou en liste (par exemple, un graphe). Dans la plupart des cas, les listes sont suffisantes et même dans certains cas, un modèle ne devrait contenir qu'une seule entrée. En particulier si vous voulez modéliser une seule entrée ayant différents attributs (une instance d'une classe), le cadre modèle/vue de Qt n'est pas le bon moyen de séparer la logique de l'interface utilisateur.
Pour résumer, je pense que le cadre modèle/vue de Qt est utile si et seulement si vos données sont visualisées par l'un des éléments suivants Les widgets de visualisation de Qt . Il est totalement inutile si vous êtes sur le point d'écrire votre propre visualiseur pour un modèle ne contenant qu'une seule entrée, par exemple les paramètres de votre application, ou si vos données ne sont pas de types imprimables.
Comment ai-je utilisé le modèle/la vue de Qt dans une (plus grande) application ?
J'ai écrit une fois (en équipe) une application qui utilise plusieurs modèles Qt pour gérer les données. Nous avons décidé de créer un DataRole pour contenir les données réelles qui étaient d'un type personnalisé différent pour chaque sous-classe de modèle. Nous avons créé une classe de modèle externe appelée Model contenant tous les différents modèles Qt. Nous avons également créé une classe de vue externe appelée View contenant les fenêtres (widgets) qui sont connectées aux modèles dans le cadre de l'activité de l'entreprise. Model . Cette approche est donc un MVC Qt étendu, adapté à nos propres besoins. Les deux sites Model et View Les classes elles-mêmes n'ont rien à voir avec le MVC de Qt.
Où avons-nous mis le logique ? Nous avons créé des classes qui effectuaient les calculs réels sur les données en lisant les données des modèles sources (lorsqu'ils étaient modifiés) et en écrivant les résultats dans les modèles cibles. Du point de vue de Qt, ces classes logiques seraient des vues, puisqu'elles se "connectent" aux modèles (pas de "vue" pour l'utilisateur, mais une "vue" pour la partie logique de l'application).
Où sont les contrôleurs ? Dans la terminologie MVC originale, les contrôleurs interprètent les entrées de l'utilisateur (souris et clavier) et donnent des commandes au modèle pour qu'il effectue l'action demandée. Puisque les vues Qt interprètent déjà les entrées de l'utilisateur, comme renommer et déplacer des éléments, cela n'était pas nécessaire. Mais ce dont nous avions besoin, c'était d'une interprétation de l'interaction de l'utilisateur qui aille au-delà des vues Qt.
