Je suis actuellement en train de développer mon propre framework PHP 5.3 HMVC appelé Alloy . Étant donné que je suis fortement investi et vendu sur HMVC, j'ai pensé que je pourrais offrir un point de vue différent, et peut-être une meilleure explication de la raison pour laquelle le HMVC devrait être utilisé et des avantages qu'il apporte.
Le plus grand avantage pratique de l'utilisation d'une architecture HMVC est la «widgetisation» des structures de contenu. Un exemple peut être des commentaires, des évaluations, des affichages de flux RSS sur Twitter ou un blog, ou l'affichage du contenu du panier pour un site Web de commerce électronique. Il s'agit essentiellement d'un élément de contenu qui doit être affiché sur plusieurs pages, et peut-être même à différents endroits, en fonction du contexte de la requête HTTP principale.
Les frameworks MVC traditionnels ne fournissent généralement pas de réponse directe pour ces types de structures de contenu, de sorte que les gens finissent généralement par dupliquer et changer de mise en page, en utilisant des assistants personnalisés, en créant leurs propres structures de widget ou fichiers de bibliothèque, ou en extrayant des données non liées à partir du principal demandé. Contrôleur pour passer à la vue et rendre dans un partiel. Aucune de ces options n'est particulièrement bonne, car la responsabilité de rendre un contenu particulier ou de charger les données requises finit par se répandre dans plusieurs zones et se dupliquer là où elle est utilisée.
HMVC, ou spécifiquement la capacité d'envoyer des sous-demandes à un contrôleur pour gérer ces responsabilités est la solution évidente. Si vous pensez à ce que vous faites, cela correspond exactement à la structure du contrôleur. Vous devez charger des données sur les commentaires et les afficher au format HTML. Vous envoyez donc une requête au contrôleur de commentaires avec quelques paramètres, il interagit avec le modèle, choisit une vue et la vue affiche le contenu. La seule différence est que vous voulez que les commentaires soient affichés en ligne, sous l'article de blog que l'utilisateur consulte au lieu d'une page de commentaires complète complètement séparée (bien qu'avec une approche HMVC, vous pouvez en fait servir des demandes internes et externes avec le même contrôleur et "tuer deux oiseaux avec une pierre ", comme on dit). À cet égard, Le HMVC n'est en réalité qu'un sous-produit naturel de la recherche d'une modularité accrue du code, d'une réutilisation et d'une meilleure séparation des préoccupations. CECI est le point de vente de HMVC.
Ainsi, bien que l'article TechPortal de Sam de Freyssinet sur la mise à l'échelle avec HMVC soit intéressant à réfléchir, ce n'est pas là que 90% + des personnes qui utilisent les frameworks HMVC vont en tirer des avantages réels, pratiques et quotidiens.