php 什么是 HMVC 模式？

What is the HMVC pattern?

提问by Matteo Riva

Reading Kohana's documentation, I found out that the main difference in 3.0 version is that it follows the HMVC pattern instead of MVC as version 2.x does. The page about this in Kohana's docs and the one on wikipedia didn't really give me a clear idea.

阅读 Kohana 的文档，我发现 3.0 版本的主要区别在于它遵循 HMVC 模式，而不是 2.x 版那样的 MVC。Kohana 的文档和维基百科上关于此的页面并没有真正给我一个清晰的想法。

So question: what is the HMVC pattern and how does it differ from MVC?

所以问题是：什么是 HMVC 模式，它与 MVC 有何不同？

采纳答案by shadowhand

Sam de Freyssinet (one of the Kohana developers) wrote a rather in-depth article about HMVC, what it is, and how it can be used.

Sam de Freyssinet（Kohana 开发人员之一）写了一篇关于 HMVC、它是什么以及如何使用它的深入文章。

Link is dead: New Link - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

链接已死：新链接 - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

回答by Vance Lucas

I am currently in the process of developing my own PHP 5.3 HMVC framework called Alloy. Since I am heavily invested in and sold on HMVC, I thought I could offer a different view point, and perhaps a better explanation of why HMVC should be used and the benefits it brings.

我目前正在开发我自己的名为Alloy的 PHP 5.3 HMVC 框架。由于我对 HMVC 进行了大量投资和销售，我想我可以提供一个不同的观点，也许可以更好地解释为什么应该使用 HMVC 以及它带来的好处。

The largest practical benefit of using an HMVC architecture is the "widgetization" of content structures. An example might be comments, ratings, Twitter or blog RSS feed displays, or the display of shopping cart contents for an e-commerce website. It is essentially a piece of content that needs to be displayed across multiple pages, and possibly even in different places, depending on the context of the main HTTP request.

使用 HMVC 架构的最大实际好处是内容结构的“小部件化”。例如，评论、评级、Twitter 或博客 RSS 提要显示，或电子商务网站的购物车内容显示。它本质上是一段需要跨多个页面显示的内容，甚至可能显示在不同的位置，具体取决于主 HTTP 请求的上下文。

Traditional MVC frameworks generally don't provide a direct answer for these types of content structures, so people generally end up duplicating and switching layouts, using custom helpers, creating their own widget structures or library files, or pulling in unrelated data from the main requested Controller to push through to the View and render in a partial. None of these are particularly good options, because the responsibility of rendering a particular piece of content or loading required data ends up leaking into multiple areas and getting duplicated in the places it is used.

传统的 MVC 框架通常不会为这些类型的内容结构提供直接的答案，因此人们通常最终会复制和切换布局、使用自定义帮助程序、创建自己的小部件结构或库文件，或者从主要请求中提取不相关的数据控制器推送到视图并在局部渲染。这些都不是特别好的选择，因为渲染特定内容或加载所需数据的责任最终会泄漏到多个区域并在使用它的地方重复。

HMVC, or specifically the ability to dispatch sub-requests to a Controller to handle these responsibilities is the obvious solution. If you think about what you're doing, it fits the Controller structure exactly. You need to load some data about comments, and display them in HTML format. So you send a request to the comments Controller with some params, it interacts with the Model, picks a View, and the View displays the content. The only difference is you want the comments displayed inline, below the blog article the user is viewing instead of a completely separate full comments page (though with an HMVC approach, you can actually serve both internal and external requests with the same controller and "kill two birds with one stone", as the saying goes). In this regard, HMVC is really just a natural byproduct of striving for increased code modularity, re-usability, and maintaining a better separation of concerns. THIS is the selling point of HMVC.

HMVC，或者特别是将子请求分派给控制器以处理这些职责的能力是显而易见的解决方案。如果你考虑一下你在做什么，它完全符合 Controller 结构。您需要加载一些关于评论的数据，并以 HTML 格式显示它们。所以你用一些参数向评论控制器发送一个请求，它与模型交互，选择一个视图，视图显示内容。唯一的区别是您希望评论内嵌显示，在用户正在查看的博客文章下方，而不是一个完全独立的完整评论页面（尽管使用 HMVC 方法，您实际上可以使用相同的控制器为内部和外部请求提供服务并“杀死”俗话说，一石两鸟”）。在这方面，HMVC 实际上只是努力提高代码模块化、可重用性和维护更好的关注点分离的自然副产品。这就是 HMVC 的卖点。

So while Sam de Freyssinet's TechPortal articleon scaling out with HMVC is interesting to think about, it's not where 90%+ of the people who use HMVC frameworks are going to get real, practical, day-to-day benefits from it.

因此，虽然Sam de Freyssinet 的 TechPortal 文章关于使用 HMVC 进行横向扩展很有趣，但这并不是 90% 以上的使用 HMVC 框架的人会从中获得真正、实用、日常的好处的地方。

回答by mjs

In Kohana, at least, an HMVC request is a HTTP request that is serviced "internally": instead of being issued over the network, it's routed, dispatched and handled by the framework itself. The similarity of the names "HMVC" and "MVC" is confusing in that it suggests an underlying connection between the terms that does not in fact exist: one is not a minor variant or modification of the other, they are completely different things. (HMVC is also described as Ajax without the client-side HTTP request.) Kohana's emphasis on, and support for "HMVC" means that the framework has strong support for a HTTP-based service oriented architecture.

至少在 Kohana 中，HMVC 请求是一个“内部”服务的 HTTP 请求：它不是通过网络发出，而是由框架本身路由、分派和处理。“HMVC”和“MVC”这两个名称的相似性令人困惑，因为它暗示了实际上并不存在的术语之间的潜在联系：一个不是另一个的微小变体或修改，它们是完全不同的东西。（HMVC 也被描述为没有客户端 HTTP 请求的 Ajax。）Kohana 对“HMVC”的强调和支持意味着该框架对基于 HTTP 的面向服务的架构有很强的支持。

The advantage of this architectural pattern is that since the same "calling convention" is used for internal and external requests, it's trivial to convert "internal" service requests to "external" requests or vice versa as the need arises.

这种架构模式的优势在于，由于内部和外部请求使用相同的“调用约定”，因此在需要时将“内部”服务请求转换为“外部”请求或反之亦然是微不足道的。

Whilst this is a sensible architectural pattern, giving it its own name seems unnecessary (Symfony2 describes the same concept "sub-requests"), and in fact the name seems to be a misnomer: there's no particular requirement or need that the requests form a hierarchy (other than the standard call graph of every imperative program); the requests could easily be recursive, for example.

虽然这是一个合理的架构模式，但给它自己的名字似乎是不必要的（Symfony2 描述了相同的概念“子请求”），事实上这个名字似乎用词不当：没有特别要求或需要请求形成一个层次结构（除了每个命令式程序的标准调用图）；例如，请求很容易递归。

[Update Apr 2011, Mar 2012:Expanded on answer in response to comments.]

[ 2011 年 4 月更新，2012 年 3 月：根据评论扩展了答案。]

回答by troelskn

HMVC is closely related to the "component based" approach to dispatching. Basically, instead of having a single dispatcher, which delegates to a controller, each controller can act as a dispatcher it self. This gives you a hierarchy of controllers. The design is more flexible and causes better encapsulation of code, but at a price of higher abstraction. Konstruktis designed around this pattern.

HMVC 与“基于组件”的调度方法密切相关。基本上，每个控制器都可以作为自己的调度程序，而不是拥有一个委托给控制器的调度程序。这为您提供了控制器的层次结构。这种设计更灵活，可以更好地封装代码，但代价是更高的抽象。Konstrukt就是围绕这种模式设计的。

See also this answer: https://stackoverflow.com/questions/115629/simplest-php-routing-framework/120411#120411

另请参阅此答案：https: //stackoverflow.com/questions/115629/simplest-php-routing-framework/120411#120411

回答by Sanjay Jain

HMVC is Hierarchical Model View Controller.In in normal MVC every GUI object has its MVC.But there is no any relation between the parent GUI object and Child GUI object unlike HMVC. In HMVC each GUI object has access to its child objects and each of child object can access to its parent object.

HMVC是Hierarchical Model View Controller。在普通的MVC中，每个GUI对象都有自己的MVC。但与HMVC不同，父GUI对象和子GUI对象之间没有任何关系。在 HMVC 中，每个 GUI 对象都可以访问其子对象，每个子对象都可以访问其父对象。

So in every view there is a parent view.Through which it can access it parent view. For in every controller there is a parent controller through which It can pass the event to parent controller (If event is not in its scope.)

所以在每个视图中都有一个父视图。通过它可以访问它的父视图。因为在每个控制器中都有一个父控制器，通过它它可以将事件传递给父控制器（如果事件不在其范围内。）

For details description please click here

详细说明请点击这里

New link is this address

新链接是这个地址