Documentation de lecture Kohana, j’ai découvert que la principale différence dans la version 3.0 est qu’il suit le modèle HMVC au lieu de MVC en tant que version 2.x est. La page à ce sujet dans les docs de Kohana et celui sur wikipedia n’a pas vraiment me donner une idée claire.
Donc la question : quel est le modèle HMVC et en quoi est-elle différente de la MVC ?
Sam de Freyssinet (un des développeurs Kohana) a écrit un article détaillé sur HMVCplutôt, ce que c’est et comment il peut être utilisé.
Je suis actuellement en train de développer ma propre PHP 5.3 HMVC cadre appelé Alliage. Depuis que je suis beaucoup investi dans et vendus sur HMVC, je pensais que je pouvais offrir un autre point de vue, et peut-être une meilleure explication de pourquoi HMVC doit être utilisé et les avantages qu'elle apporte.
Le plus grand avantage pratique de l'aide d'un HMVC l'architecture est la "widgetization" de contenu structures. Un exemple pourrait être les commentaires, les notations, Twitter ou un blog flux RSS affiche, ou l'affichage du contenu d'un panier pour un site e-commerce. C'est essentiellement un morceau de contenu qui doit être affichée sur plusieurs pages, et peut-être même dans des endroits différents, en fonction du contexte de la principale requête HTTP.
MVC traditionnel cadres ne présentent généralement pas une réponse directe à ces types de contenu structures, afin que les gens finissent généralement par la duplication de commutation et mises en page, à l'aide de l'aide personnalisée, la création de leur propre widget des structures ou des fichiers de la bibliothèque, en traction ou en indépendants des données à partir de la principale demande du Contrôleur de pousser à travers la Vue et les afficher dans une partielle. Aucune de ces sont particulièrement bonnes options, car la responsabilité de rendu d'un élément de contenu ou le chargement de données requis finit par couler dans de multiples domaines et se dupliqué dans les endroits où il est utilisé.
HMVC, ou plus précisément la capacité de distribuer les sous-requêtes à un Contrôleur pour gérer ces responsabilités est la solution la plus évidente. Si vous pensez à ce que vous êtes en train de faire, elle s'inscrit le Contrôleur de structure exactement. Vous avez besoin de charger des données sur les commentaires, et de les afficher au format HTML. Afin de vous envoyer une demande pour les commentaires Contrôleur avec certains 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 les commentaires affichés en ligne, ci-dessous l'article du blog de l'utilisateur est affiché au lieu de séparer complètement pleine page de commentaires (mais avec un HMVC approche, vous pouvez réellement servir les demandes internes et externes avec le même contrôleur et "tuer deux oiseaux avec une pierre", comme le dit l'adage). À cet égard, HMVC est vraiment juste un sous-produit naturel de lutter pour une augmentation de code de la modularité, réutilisation, et de maintenir une meilleure séparation des préoccupations. C'est le point de vente de HMVC.
Ainsi, alors que Sam de Freyssinet TechPortal article sur la mise à l'échelle avec HMVC est intéressant de réfléchir, il n'est pas là de 90% des personnes qui utilisent HMVC cadres vont devenir réel, pratique, au jour le jour des avantages.
HMVC est étroitement liée à la composante "approche" fondée sur l'expédition. En gros, au lieu d'avoir un seul répartiteur, qui délègue à un contrôleur, chaque contrôleur peut agir comme un répartiteur de soi. Cela vous donne une hiérarchie de contrôleurs. Le design est plus souple et provoque une meilleure encapsulation de code, mais à un prix plus élevé d'abstraction. Konstrukt est conçu autour de ce modèle.
Voir aussi cette réponse: http://stackoverflow.com/questions/115629/simplest-php-routing-framework/120411#120411
Dans Kohana, au moins, un HMVC requête est une requête HTTP qui est desservi "interne": au lieu d'être émis sur le réseau, il est acheminé, distribué et géré par le framework lui-même. La similitude des noms "HMVC" et "MVC" est source de confusion en ce qu'elle suggère une connexion sous-jacente entre les termes qui n'existent pas: on n'est pas d'une variante mineure ou de la modification de l'autre, ils sont des choses complètement différentes. (HMVC est aussi décrit comme Ajax sans le côté client de la requête HTTP.) Kohana l'accent sur, et le soutien de "HMVC" signifie que le cadre a un soutien fort pour un HTTP basée sur une architecture orientée service.
L'avantage de ce modèle architectural est que, depuis la même "convention d'appel" est utilisé pour les demandes internes et externes, il est trivial de les convertir en "interne" des demandes de service "externe" des demandes ou vice-versa, comme le besoin s'en fait sentir.
Alors que c'est un bon modèle d'architecture, en lui donnant 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 aucune exigence particulière ou un besoin que les demandes forment une hiérarchie (autres que la norme du graphe d'appel de chaque programme impératif); les demandes pourraient facilement être récursive, par exemple.
[Mise à jour Avril 2011, mars 2012: Étendu sur la réponse en réponse à des commentaires.]
HMVC est Hiérarchique Modèle-Vue-Contrôleur.En normal MVC chaque objet graphique a son MVC.Mais il n'y a aucune relation entre le parent de l'objet graphique et de l'Enfant objet graphique contrairement à HMVC. Dans HMVC chaque objet graphique a accès à son enfant des objets et chaque objet enfant peut accéder à son objet parent.
Ainsi, dans chaque vue, il est un parent de la vue.Grâce à laquelle il peut accéder à la vue parente. Pour chaque contrôleur il y a un contrôleur de parent à travers lequel Il peut transmettre l'événement de contrôleur de parent (Si l'événement n'est pas dans son champ d'application.)
Pour plus de détails description, veuillez cliquer ici
Nouveau lien est cette adresse
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
