MVC, base de données et client lourd

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!

Bonjour,

Il y a plusieurs aspects dans ta question :

• Le fait que l'application soit du MVC me parait orthogonal à la problématique d'accès aux données. MVC est essentiellement un pattern de présentation. La partie Model est entièrement laissée à la discrétion du développeur et on voit des interprétations totalement différentes de ce qu'est un Model : modèle taillé pour la vue avec des objets qui s'apparentent à des DTO contenant juste les données à afficher, modèle contenant les "vrais" objets métiers que le Contrôleur ou la Vue vont directement manipuler, etc.
  
  Pareil pour le fait que ça soit un client lourd : cela ne fait que rassembler sur la même machine plusieurs couches logicielles qui autrement auraient été distribuées sur plusieurs tiers physiques. La problématique de construction d'une couche logique d'accès aux données qui va communiquer avec le stockage persistant est toujours là et reste inchangée.

• Concernant le chargement des données, dans la plupart des cas récupérer toute une ligne plutôt que certaines colonnes aura peu d'impact sur les performances, le SGBD étant capable de lire la ligne en une seule fois. En revanche, si on charge de multiples lignes, et à fortiori des lignes provenant de plusieurs tables, le coût augmente. Plus rarement, le coût peut aussi augmenter si la table contient des colonnes de grande taille de type BLOB ou CLOB.
  
  Pour ces deux dernier cas, on peut utiliser un système de lazy loading afin d'éviter de remonter à chaque fois depuis la base un objet et tout son graphe de dépendances, ou bien des colonnes volumineuses alors qu'on veut juste accéder à une ou deux propriétés simples de cet objet. Les frameworks de mapping objet/relationnel proposent pour la plupart du lazy loading nativement.
  
  Cf http://stackoverflow.com/questions/1...rom-a-database

• Sur la partie "le modèle devrait récupérer l'enregistrement..." : en réalité c'est souvent une couche bien spécifique au sein du Modèle (au sens MVC) qui devrait s'occuper de charger les données depuis le stockage persistant. Il s'agit de la couche d'accès aux données (DAL). Pourquoi créer une couche spécifique pour ça ? Pour découpler la couche métier, qui contient les règles et objets métier valables tout le temps et qu'on peut éventuellement réutiliser dans une autre application, du mécanisme d'accès aux données, qui est de l'infrastructure bas niveau et est très spécifique au stockage physique sous-jacent (base de données relationnelle ou autre).
  
  Dans les applications complexes, ce ne sont donc souvent pas les objets métiers eux-mêmes qui récupèrent les données en base, mais des objets spécialisés de la couche DAL : DAO, Repositories, ou autres.

Pour moi il est important au final que les objets métier présentent une façade claire et fidèle à la vision métier quoi qu'il arrive. Ils ne devraient pas être pollués par des problématiques relevant du chargement des données. Du code qui manipule un objet de type Page devrait toujours voir cet objet comme un tout cohérent et ne devrait pas avoir à connaitre la tambouille sous-jacente : lorsqu'on veut accéder à la Miniature de la Page, ce n'est pas notre problème de savoir si la donnée est déjà présente en mémoire ou s'il faut faire une requête supplémentaire en base pour aller la chercher.

Tout d'abord, merci d'avoir pris le temps de répondre :)

Pour essayer de cibler un peu plus ma problématique, je m'intéresse surtout à ce que seraient les bonnes pratiques concernant la "façon" d'accéder à une DB (fréquence, volume des données, ...). En effet, cela n'est pas une problématique spécifique à l'aspect Model du MVC. Du coup, ce sujet n'a peut être plus forcément sa place dans la section "MVC" :/ Mais c'est bien, d'en discuter ça m'a permis de bien m'en rendre compte :) Quand on est seul sur un projet, et qu'un aspect pose problème, on en arrive vite à tourner en rond!
C'est vrai que c'était un peu un abus de langage quand je parlais du modèle qui accède à la DB. Je conçois tout à fait qu'il y aura un certain nombre de couche à mettre en place afin de gérer tout ça. D'ailleurs, malgré mes recherches sur les ORM, je n'étais pas tombé sur le terme de lazy loading, qui correspond en fait à une des solutions que j'avais envisagé.
J'avais également envisagé une représentation des objets métier, mais contenant la gestion accès à la DB, et j'avoue que ce couplage me génait un peu. Le concept de DAO est du coup très intéressant car il permet de faire abstraction de la couche de stockage (si j'ai bien compris).

Bref, la problématique de l'accès aux données n'est pas fondamentalement liée au MVC, et j'ai quand même appris quelques trucs intéressants pour mon projet!
Merci bien :)

Citation:

---

Envoyé par vravier

Le concept de DAO est du coup très intéressant car il permet de faire abstraction de la couche de stockage (si j'ai bien compris).

---

Oui, c'est bien ça.

Si tu cherches des conseils sur la façon d'architecturer ton accès aux données, je te recommande le bouquin Patterns of Enterprise Application Architecture de Fowler qui contient pas mal de modèles de conception largement répandus sur l'accès aux données, la gestion des transactions, le change tracking, etc.