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 me donnaient pas vraiment une idée claire.
Alors question: qu'est-ce que le modèle HMVC et en quoi diffère-t-il de MVC?
Sam de Freyssinet (un des développeurs de Kohana) a écrit un article 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 en train de développer mon propre PHP 5.3 framework HMVC appelé Alloy. Comme je suis fortement investi et vendu sur HMVC, je pensais pouvoir offrir un point de vue différent et peut-être une meilleure explication de la raison pour laquelle HMVC devrait être utilisé et des avantages qu’il apporte.
Le plus grand avantage pratique d'utiliser une architecture HMVC est la "widgetisation" des structures de contenu. Par exemple, les commentaires, les évaluations, les affichages de flux RSS sur Twitter ou sur les blogs, ou l’affichage du contenu du panier pour un site Web de commerce électronique. Il s'agit essentiellement d'un contenu qui doit être affiché sur plusieurs pages, voire éventuellement à des endroits différents, en fonction du contexte de la requête HTTP principale.
Les frameworks traditionnels de MVC ne fournissent généralement pas de réponse directe pour ces types de structures de contenu. Ainsi, les utilisateurs finissent généralement par dupliquer et changer de présentation, en utilisant des aides personnalisées, en créant leurs propres structures de widget ou fichiers de bibliothèque, ou en extrayant des données non liées des données principales demandées. Contrôleur pour accéder à la vue et le rendre partiel. Aucune de ces options n'est particulièrement intéressante, car la responsabilité de restituer un contenu particulier ou de charger les données requises finit par fuir dans de multiples zones et de se dupliquer aux endroits où elle est utilisée.
La solution évidente est HMVC, ou plus précisément la possibilité d’envoyer des sous-demandes à un contrôleur pour s’acquitter de ces responsabilités. Si vous pensez à ce que vous faites, cela correspond parfaitement à 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 certains paramètres, il interagit avec le modèle, sélectionne une vue et cette vue affiche le contenu. La seule différence est que vous souhaitez afficher les commentaires en ligne, en dessous de 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 puissiez réellement répondre aux demandes internes et externes avec le même contrôleur et "kill". deux oiseaux avec une pierre ", comme dit le proverbe). À cet égard, HMVC est simplement un sous-produit naturel de la volonté d’améliorer la modularité du code, la possibilité de le réutiliser et de maintenir une meilleure séparation des problèmes. CECI est le point de vente de HMVC.
Donc, bien qu'il soit intéressant de penser à l'article sur le TechPortal de Sam de Freyssinet avec HMVC, il n'est pas intéressant de penser que ce n'est pas là que 90% ou plus des utilisateurs des frameworks HMVC vont devenir réels, pratiques, à la journée. aujourd'hui en profite.
Au moins, dans Kohana, une requête HMVC est une requête HTTP traitée "en interne": au lieu d'être émise sur le réseau, elle est routée, distribuée et gérée par l'infrastructure elle-même. La similitude des noms "HMVC" et "MVC" est source de confusion en ce qu’elle suggère un lien sous-jacent entre les termes qui n’existent pas réellement: l’un n’est pas une variante ou une modification mineure de l’autre, ils 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" signifient que la structure prend en charge de manière solide une architecture orientée service basée sur HTTP.
L'avantage de ce modèle architectural est que, dans la mesure où la même "convention d'appel" est utilisée pour les demandes internes et externes, il est simple de convertir les demandes de service "internes" en demandes "externes" ou inversement selon les besoins.
Bien qu'il s'agisse d'un modèle architectural judicieux, lui donner son propre nom semble inutile (Symfony2 décrit le même concept " sous-requêtes "), et le nom semble en fait être impropre: il n'y a pas d'exigence particulière ou besoin que les demandes forment une hiérarchie (autre que le graphe d'appels standard de chaque programme impératif); les demandes pourraient facilement être récursives, par exemple.
[ Mise à jour avril 2011, mars 2012: Développé après réponse en réponse aux commentaires.]
HMVC est étroitement liée à l’approche de répartition basée sur les composants. Fondamentalement, au lieu d’avoir un seul répartiteur, qui délègue à un contrôleur, chaque contrôleur peut jouer le rôle de répartiteur lui-même. Cela vous donne une hiérarchie de contrôleurs. La conception est plus flexible et provoque une meilleure encapsulation du code, mais au prix d'une abstraction plus élevée. Konstrukt est conçu autour de ce modèle.
Voir aussi cette réponse: https://stackoverflow.com/questions/115629/simplest-php-routing-framework/120411#120411
HMVC est un contrôleur de vue de modèle hiérarchique. Dans MVC normal, chaque objet GUI a son MVC.Mais il n'y a pas de relation entre l'objet GUI parent et l'objet Child GUI contrairement à HMVC. En HMVC, chaque objet graphique a accès à ses objets enfants et chaque objet enfant peut accéder à son objet parent.
Ainsi, dans chaque vue, il existe une vue parent. Par le biais de laquelle il peut accéder à la vue parent. Car dans chaque contrôleur, il existe 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