Bonjour,
Je dois redévelopper un client lourd (en C++), reposant sur une base de données. Le MVC étant pour moi simplement du bon sens, j'oriente la phase de réflexion/conception dans ce sens. Ca fait une dizaine d'années que je suis programmeur, mais c'est la première fois que je développe professionnellement un client se servant d'une DB, et j'aimerai avoir l'avis d'autres personnes expérimentées sur un point.
Le principe du MVC étant de découpler les différents aspects d'une appli, le modèle ne doit a priori pas interroger la DB en fonction des données que veulent afficher telle ou telle vue. Donc le modèle devrait récupérer l'enregistrement entier lorsque qu'une vue veut en afficher ne serait-ce qu'une donnée. Dès lors se pose la question de la place mémoire qui va être occupée par, par exemple, une simple recherche affichant 3 colonnes sur les 20 disponibles dans une table. Le modèle va tout charger en mémoire. On pourrait sinon prendre le parti de ne charger que les données nécessaires à chaque vue, mais du coup on spécialise des fonctions de chargement de données dans le modèle pour des vues spécifiques, sans parler de la gestion pour savoir si telle donnée a été chargée ou pas pour un enregistrement déjà en mémoire. Je trouve que cette solution s'éloigne du principe du MVC... Je ne parle même pas de la solution de charger les données en stockant à chaque fois ce dont à besoin une vue, ce qui dupliquerait plein de truc en mémoire.
Pour le moment, je suis plutot parti sur le principe que le modèle charge un enregistrement entier depuis la DB. Il y a peut-être mieux, mais j'ai beau retourner le problème dans tous les sens je ne vois pas...
Prenons un exemple pour pouvoir discuter sur du concret: pour faire l'analogie avec le modèle de données dont je dispose, disons qu'on dispose d'une DB stockant les infos sur des livres, dont on a les scans de quelques pages. Grosso merdo on a un truc du genre:
Table LIVRE:
- ID (clé primaire)
- Titre
- Auteur
- Collection
- Année
- Résumé
Table PAGE:
- ID (clé primaire)
- IDLivre (clé étrangère sur LIVRE:ID)
- Image
- Miniature
Concernant les vues, admettons qu'il y ait une vue "Recherche" qui sorte une liste de livre en affichant que les titres et auteurs, et une autre vue "Détail" qui affiche toutes les infos d'un livre, et toutes les miniatures de page s'y rapportant.
Le problème est somme toute assez simple, et quiconque a développé un client avec une DB derrière en utilisant le concept de MVC a certainement dû le rencontrer! Je serai intéressé d'avoir un retour sur les choix de conception faits, et les implications.
Je suis conscient que le MVC est un concept, et donc forcément quelque fois difficile à appliquer. Néanmoins il impose quelques bonnes pratiques, comme la programmation évènementielle (très à propos pour une appli reposant principalement sur les actions de l'utilisateur), et le stockage unique des données en mémoire.
Avis à la population!
Partager