Conception Modèle – Vue – Contrôleur

Je vous propose plusieurs billets, sur la conception logicielle de qualité.

Une bonne pratique, quand on veut faire du logiciel de qualité, c’est de séparer les fonctions en « couches ».

Ainsi, on a l’habitude, pour un système de publication web (e-commerce ou autre CMS) de séparer les choses en trois couches :

  1. Couche Présentation
  2. Couche « applicative »
  3. Couche d’accès aux données

C’est ce qu’on appelle le modèle MVC : Modèle Vue Contrôleur.

La première couche est simple à définir : c’est tout ce qui touche à la génération de la page HTML. Normalement, le code HTML doit être exclusivement regroupé dans cette couche.

Le dernière couche est également simple à comprendre : elle doit couvrir l’ensemble des accès au système de stockage des données : la base de données quoi. Elle regroupe donc, si le système est basé sur une base de données relationnelles, l’ensemble des accès SQL (il ne doit donc pas y en avoir sur les autres couches).

A partir de ces deux définitions, on peut déduire que la couche du milieux contient… le reste.

L’avantage de cette approche :

On ne mélange pas tout. Programmer l’accès à une base de données, ou programmer une interface HTML, ce n’est pas du tout la même chose.

Normalement, cela doit permettre de faire évoluer le site plus vite, d’améliorer sa qualité (moins de bugs).

Je dis normalement, parce qu’il faut bien savoir que… un mauvais programmeur fera du mauvais travail, quelque soit les règles qu’on peut mettre en place.

Autre paradoxe : programmer comme cela, en couche, cela augmente mécaniquement la taille du code.

Le programme le plus court sera celui ou vous mélangez tout…

Et pourtant, là aussi mécaniquement, moins il y a de code, et moins il y a risque de bug.

On est donc à la recherche d’un juste milieu.

Bon, ceci dit, personne de vraiment sérieux ne remet en cause le modèle de ces trois couches.

D’ailleurs, la plupart des plate formes e-commerce respectent cette structure : Magento, Prestashop, …

8 commentaires

  1. Salut,

    Quelle bonne idée de parler un peu du MVC, qui est une structure encore inconnue par une partie des développeurs.

    En ce qui concerne Prestashop, effectivement ils appliquent le concept du MVC, cependant je pense que le découpage peut-être amélioré, leurs conventions ne sont pas assez strictes et permettent au développeur de faire « ce qui lui plaît ».

    Si Prestashop reposait sur un véritable framework, cela impliquerait plus de conventions et encore une meilleure lisibilité, stabilité du code. A voir dans 1 ou 2 ans comment le produit continue son évolution.

  2. Il faut aussi voir le concept MVC (ou Design Pattern pour les puristes) comme la séparation des activités. En effet le développeur n’est pas toujours celui qui gère l’intégration des maquettes HTML ni celui qui écrit les requêtes SQL ou les procédures stockées.
    MVC permet alors des accès séparés et des responsabilités délimitées entre Présentation, Processing et Accès aux données.

  3. @Webbax> Le découplage entre les couches est bien souvent un sujet délicat 😉

    @Blackarma> Le modèle MVC est l’un des pattern. Design Parttern en propose bien d’autres !

  4. Bonjour François,

    Effectivement, peu de gens remettent en question le tryptique Données/Traitement/Présentation dans un Système d’Informations (d’ailleurs, qu’il s’agisse de E-Commerce ou de Comptabilité, c’est la même chose).

    Si je souscrit totalement au fait que le programme le plus court est celui qui aura le moins de bugs, je ne suis pas d’accord que le programme le plus court est celui où tout est mélangé. Au contraire, une bonne séparation, permet d’isoler des invariants techniques, et d’envisager une réutilisation bien meilleure, donc de disposer de moins de code pour une application.

    BTW, c’est un peu ce que l’on fait chez Aspectize. Programmer l’accès à une base de données, ou programmer une interface HTML n’est effectivement pas la même chose, et nous, on prétend que ni l’un ni l’autre n’ont besoin d’être « programmés », mais qu’une approche déclarative suffit, et est beaucoup plus efficace. Du coup, on est passé du MVC au MVS (Modele-Vue-Service), on a éliminé le C dans l’affaire. Bon, on est encore un peu tout seul à le proposer, (et on ne fait pas encore d’e-commerce), mais quand on montre nos projets réalisés avec un minimum de code écrit, on nous regarde différemment ;-)…

    A bientôt,

  5. Gros débat. Pour le puriste, dont j’aurais tendance à faire partie, le modèle MVC est super , lisible, maintenable à souhait, mais finalement excessivement lourd à coder.
    Tout dépend dans quel contexte on travaille.
    Si on a une logique Editeur de logiciel, MVC s’impose car il force à définir des conventions , la prise en main du code par un développeur est plus longue , mais a terme c’est payant en limitant le support lié au bug.
    Par contre, si une entreprise se code son propre spécifique (bien souvent en partant d’une base OpenSource pour dégrossir …) il est plus rentable de développer « tout mélangé » car parfois les réalités commerciales forcent à être plus réactifs
    ‘Ex changer une politique de points de fidélité, tester un concept commercial etc etc)
    C’est pourquoi dés fois on préfère « bricoler » rapidement un OsCommerce hyper rapide en exécution plutôt que passer du temps en palabres et formalisation.

    Par contre sur d’autres sujets « Boutiques complexes », gestion de contenus , le MVC s’impose (J’adore MAGENTO qui a poussé très loin le modèle) à condition de savoir vendre cette techno au client qui ne comprend pas bien la différence, mais qui vous reprochera très vite un manque de réactivité et les coût en cutumisation de serveur.

    Bien à vous.

    Alors un code bien fait sans client ou un code imparfait avec des clients …. ???

  6. En fait, @Anonyme a raison : le poids du code dépend de l’environnement de développement. Dans un monde idéal, on pourrait séparer en couche et pas être trop lourd en code.

    Maintenant, la réalité du web est bien loin de cette vision ! Magento, qui est effectivement allé assez loin, est plutôt verbeux.

  7. @François: absolument, il y’a tout un catalogue de pattern et MVC en est un. (je me suis mal exprimé)

    @Richard : tôt ou tard lorsque l’on code tout en mélangé, même pour du code interne, les développements finissent par couter plus cher.

  8. François le modèle MVC ça ne serait pas plutôt :

    Couche Présentation : le vue qui ne contient que de la « logique » d’affichage et aucune règle de gestion mis à part du contrôle de surface

    Couche Contrôle : qui gère les évènements déclenchés par l’utilisateur et appelles les actions correspondante.

    Couche Modèle : qui contient, comme tu l’as dit, tout le reste, comme les règles de gestion l’accès aux données, etc …
    Je pense qu’il faut encore découper derrière pour pouvoir réutiliser le plus possible.

    Les couches à ajouter sont comme tu le dis, une couche d’accès aux données DAO. J’ajoute souvent aussi une couche service entre la couche modèle du MVC et la couche DAO. En effet je n’aime pas trop laisser des objet DAO se balader niveau présentation, ni avoir trop de règles de gestion dupliquée entres les cas d’utilisation ce qui arrivent si tu mets tout dans la couche modèle qui représente un UC …

    Je code en java et pour chacune des couches ainsi citées il y a des frameworks géniaux, comme Spring MVC, Struts, Hibernate, Spring-core etc…

    Dans tes prochains billets tu pourrais peut-être parler de la programmation orientée aspect (AOP) qui est une façon de programmer à part entière ? Mais aussi du pattern Inverion of Control (IoC) qui est à la base du framework Spring et qui a révolutionné la façon de séparer les couches d’une appli.

    Concernant la taille du code il est clair que chaque couche ajouté te coûte en ligne de code. Mais la maintenance est facilité par une clarté du code, une séparation des responsabilités, une non adhérence des objets.

    Beau billet François.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *