Quel est le modèle HMVC?

En lisant la documentation de Kohana, j'ai découvert que la principale différence dans la version 3.0 est qu'elle suit le modèle HMVC au lieu de MVC comme le fait la version 2.x. La page à ce sujet dans la documentation de Kohana et celle sur wikipedia ne m'ont pas vraiment donné une idée claire.

Alors question: quel est le modèle HMVC et en quoi diffère-t-il de MVC?

Sam de Freyssinet (l'un des développeurs de Kohana) a écrit un article assez approfondi sur HMVC , ce que c'est et comment il peut être utilisé.

Le lien est mort: Nouveau lien - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

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.

Le HMVC est étroitement lié à l'approche «basée sur les composants» de la répartition. Fondamentalement, au lieu d'avoir un seul répartiteur, qui délègue à un contrôleur, chaque contrôleur peut agir comme un répartiteur lui-même. Cela vous donne une hiérarchie de contrôleurs. Le design est plus flexible et permet une meilleure encapsulation du code, mais à un prix d'abstraction plus élevé. Konstrukt est conçu autour de ce modèle.

Voir aussi cette réponse: /programming/115629/simplest-php-routing-framework/120411#120411

Dans Kohana, au moins, une requête HMVC est une requête HTTP qui est servie "en interne": au lieu d'être émise sur le réseau, elle est routée, distribuée et gérée par le framework lui-même. La similitude des noms "HMVC" et "MVC" prête à confusion en ce qu'elle suggère un lien sous-jacent entre les termes qui n'existe pas en fait: l'un n'est pas une variante mineure ou une modification de l'autre, ce sont des choses complètement différentes. (HMVC est également décrit comme Ajax sans la requête HTTP côté client.) L'accent mis par Kohana sur et la prise en charge de "HMVC" signifie que le framework prend en charge une architecture orientée service basée sur HTTP.

L'avantage de ce modèle architectural est que puisque la même «convention d'appel» est utilisée pour les requêtes internes et externes, il est trivial de convertir des requêtes de service «internes» en requêtes «externes» ou vice versa selon le besoin.

Bien qu'il s'agisse d'un modèle architectural raisonnable, lui donner son propre nom semble inutile (Symfony2 décrit le même concept de « sous-requêtes »), et en fait le nom semble être un abus de langage : il n'y a pas d'exigence ou de besoin particulier que les requêtes forment un hiérarchie (autre que le graphe d'appel standard de chaque programme impératif); les requêtes pourraient facilement être récursives, par exemple.

[ Mise à jour avril 2011, mars 2012: réponse détaillée aux commentaires.]

HMVC est Hierarchical Model View Controller.Dans le MVC normal, chaque objet GUI a son MVC.Mais il n'y a aucune relation entre l'objet GUI parent et l'objet GUI enfant contrairement à HMVC. Dans HMVC, chaque objet GUI a accès à ses objets enfants et chaque objet enfant peut accéder à son objet parent.

Ainsi, dans chaque vue, il y a une vue parent, à travers laquelle elle peut accéder à la vue parent. Car dans chaque contrôleur, il y a un contrôleur parent à travers lequel Il peut transmettre l'événement au contrôleur parent (si l'événement n'est pas dans sa portée.)

Pour plus de détails, veuillez cliquer ici

Le nouveau lien est cette adresse