Le Pattern HMVC

Dans cet article, je vais vous parler d’un autre pattern, celui du HMVC, qui n’est à mon sens pas assez connu et utilisé.

HMVC ? Qu’est ce que c’est ?

Le HMVC (Hierarchical Model View Controller ) est un patron d’architecture, tout comme le MVC. D’ailleurs, il utilise la même architecture avec le trio Model – View – Controller, à la différence qu’il est possible (et c’est le but) de hiérarchiser chaque composant :

Pattern MVC :

Pattern MVC

Pattern HMVC :

Pattern HMVC

Au lieu d’avoir un super contrôleur qui appelle toutes les fonctions, toutes les classes et qui génère lui même les vues de tous les composants, on laisse à chaque module sa responsabilité, son contrôleur, modèle et vue.

Ainsi le router redirige vers un module en fonction de la requête, qui lui-même effectuera des sous-requêtes vers d’autres modules.

Ça donne quoi dans le code ?

Imaginons un site web assez simple :
Un blog où l’on affiche un article, et celui-ci comprend des commentaires. Nous avons une box de connexion si l’utilisateur n’est pas connecté, et un affichage de toutes les catégories des articles.

Voilà à quoi ça pourrait ressembler en MVC ‘classique’ :

Et dans la vue associée :

Je sais, mon code est un gruyère mais c’est voulu, c’est uniquement pour arriver là où je le souhaite 🙂 :
Le contrôleur Article s’occupe de tout, des articles bien sûr, mais aussi des commentaires, catégories, … Et si mon site web était plus complexe, vous imaginez le résultat ?

Bien sûr, on pourrait créer des tas de librairies ou de helpers qui iraient récupérer toutes ces informations, mais est-ce là la meilleure manière de procéder ?

Voilà à quoi ressemblerait notre code Article maintenant, en HMVC :

Le contrôleur Articles :

La vue associée :

On imaginera ici les modules User, Comments et Categories qui, une fois appelés par la vue du module Articles, retourneront chacun une vue.

Tout est module !

Avec le HMVC, tout devient un module. Ça me rappelle la phrase que je voyais souvent lorsque je me mettais à la POO : Tout est objet ! ^^

Et oui, chaque composant du site peut devenir un module indépendant :

  • Les commentaires
  • La partie ‘user’
  • Les articles
  • Système social (Facebook, Twitter etc)
  • Un forum
  • Les news
  • ……………………………….

Bien sûr, il faudra configurer le router ou le framework : L’utilisateur ne peut pas arriver directement sur le module Commentaires par exemple. S’il n’est pas lié à un article ou autre contenu, un commentaire seul n’a pas de sens 😉

Vive l’indépendance

L’avantage indéniable de cette pratique est l’indépendance de chaque module. Chacun fait son job, et uniquement le sien, ce qui permet également la réusabilité : Chaque partie du site étant indépendante, il est possible d’en prendre une ou plusieurs et les appliquer à un autre projet.

Personnellement, j’apprécie également le fait d’avoir de plus légers contrôleurs et de séparer les responsabilités, mais ça c’est au goût de chacun.

Et c’est pas fini ! Imaginons dans le code de notre blog que nous souhaitons supprimer complètement la fonctionnalité des commentaires.
Coté MVC, il va falloir supprimer chaque référence aux commentaires dans les contrôleurs, modèles et vues.
En revanche, en HMVC, il suffit de supprimer le dossier du module et supprimer les appels dans les vue du module Articles. C’est pas la classe ça ? 😉

Le mot de la fin

J’espère que ce billet, bien qu’ assez abstrait car il ne permet pas de comprendre comment mettre en place ce patron de conception à partir de rien,  vous aura permit de comprendre ce qu’était le pattern HMVC.
N’hésitez pas à donner votre avis !

1 Commentaire

Ajouter un commentaire

  1. Je suis parfaitement d’accord avec l’idée de « décomposer » ces monstrueux contrôleurs qu’on trouve parfois dans les archi MVC.
    Mais finalement, j’ai l’impression qu’on réinvente le paradigme objet: chaque classe est un petit M(membres)V(signatures des méthodes)C(contenu des méthodes), et les groupements de classe (modules) sont des applications du design pattern Facade.

Laisser un commentaire

Votre adresse mail ne sera pas publiée.

*

© 2017 Max-Koder — Propulsé par WordPress

Theme par Anders NorenHaut ↑