Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MVC Discussion :

MVC, base de données et client lourd


Sujet :

MVC

  1. #1
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2011
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Service public

    Informations forums :
    Inscription : décembre 2011
    Messages : 54
    Points : 67
    Points
    67
    Par défaut 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!

  2. #2
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 930
    Points
    2 930
    Par défaut
    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.

  3. #3
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2011
    Messages
    54
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Service public

    Informations forums :
    Inscription : décembre 2011
    Messages : 54
    Points : 67
    Points
    67
    Par défaut
    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

  4. #4
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 930
    Points
    2 930
    Par défaut
    Citation Envoyé par vravier Voir le message
    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.

Discussions similaires

  1. Réponses: 27
    Dernier message: 02/08/2013, 10h47
  2. [C#] [MVC]Base de données distante
    Par DotNET74 dans le forum Débuter
    Réponses: 3
    Dernier message: 21/02/2013, 08h18
  3. Réponses: 2
    Dernier message: 24/09/2012, 12h56
  4. Déclencher un événement de modification de base de données au client web
    Par Akhdar dans le forum Développement Web en Java
    Réponses: 3
    Dernier message: 07/06/2011, 19h37
  5. [XL-2007] connexion base de donnée en client
    Par raph-68i dans le forum Macros et VBA Excel
    Réponses: 3
    Dernier message: 11/05/2010, 17h45

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo