阅读 Kohana 的文档，我发现 3.0 版本的主要区别在于它遵循 HMVC 模式，而不是像 2.x 版本那样遵循 MVC。 Kohana 的文档和维基百科上关于此的页面并没有真正给我一个明确的想法。
那么问题：什么是 HMVC 模式，它与 MVC 有何不同？
【问题讨论】：
Sam de Freyssinet（Kohana 开发人员之一）写了一个相当 in-depth article about HMVC，它是什么以及如何使用它。
【讨论】：
我目前正在开发自己的名为 Alloy 的 PHP 5.3 HMVC 框架。由于我对 HMVC 进行了大量投资和推销，我想我可以提供一个不同的观点，或许可以更好地解释为什么应该使用 HMVC 以及它带来的好处。
使用 HMVC 架构的最大实际好处是内容结构的“小部件化”。一个示例可能是 cmets、评级、Twitter 或博客 RSS 提要显示，或电子商务网站的购物车内容显示。它本质上是一段内容，需要跨多个页面显示，甚至可能在不同的地方显示，具体取决于主要 HTTP 请求的上下文。
传统的 MVC 框架通常不会为这些类型的内容结构提供直接的答案，因此人们通常会复制和切换布局、使用自定义帮助程序、创建自己的小部件结构或库文件，或者从主要请求的控制器推送到视图并部分渲染。这些都不是特别好的选择，因为渲染特定内容或加载所需数据的责任最终会泄漏到多个区域并在使用它的地方重复。
HMVC，或者特别是向控制器发送子请求以处理这些职责的能力是显而易见的解决方案。如果您考虑一下自己在做什么，它完全符合 Controller 结构。您需要加载一些有关 cmets 的数据，并以 HTML 格式显示它们。因此，您使用一些参数向 cmets 控制器发送请求，它与模型交互，选择一个视图，视图显示内容。唯一的区别是您希望在用户正在查看的博客文章下方内联显示 cmets，而不是完全独立的完整 cmets 页面（尽管使用 HMVC 方法，您实际上可以使用相同的控制器和“kill一石两鸟”，俗话说）。在这方面，HMVC 实际上只是努力提高代码模块化、可重用性和保持更好的关注点分离的自然副产品。这是HMVC的卖点。
因此，尽管Sam de Freyssinet's TechPortal article 关于使用 HMVC 进行横向扩展的思考很有趣，但这并不是 90% 以上的使用 HMVC 框架的人会从中获得真正、实用的日常收益的地方。
【讨论】：
HMVC 与“基于组件”的调度方法密切相关。基本上，每个控制器都可以充当自己的调度程序，而不是拥有一个委托给控制器的调度程序。这为您提供了控制器的层次结构。该设计更灵活，可以更好地封装代码，但代价是更高的抽象。 Konstrukt 就是围绕这种模式设计的。
另请参阅此答案：https://stackoverflow.com/questions/115629/simplest-php-routing-framework/120411#120411
【讨论】：
至少在 Kohana 中，HMVC 请求是“内部”服务的 HTTP 请求：它不是通过网络发出的，而是由框架本身路由、分派和处理的。 “HMVC”和“MVC”这两个名称的相似性令人困惑，因为它暗示了实际上并不存在的术语之间的潜在联系：一个不是另一个的次要变体或修改，它们是完全不同的东西。 （HMVC 也被描述为没有客户端 HTTP 请求的 Ajax。）Kohana 对“HMVC”的强调和支持意味着该框架对基于 HTTP 的面向服务的架构具有强大的支持。
这种架构模式的优势在于，由于对内部和外部请求使用相同的“调用约定”，因此在需要时将“内部”服务请求转换为“外部”请求或反之亦然是微不足道的。
虽然这是一种合理的架构模式，但给它自己的名字似乎是不必要的（Symfony2 描述了相同的概念“sub-requests”），事实上这个名字似乎是用词不当：没有特别的要求或需要请求形成层次结构（每个命令式程序的标准调用图除外）；例如，请求很容易递归。
[2011 年 4 月、2012 年 3 月更新：针对 cmets 扩展了答案。]
【讨论】：
HMVC 是分层模型视图控制器。在普通 MVC 中，每个 GUI 对象都有自己的 MVC。但是与 HMVC 不同，父 GUI 对象和子 GUI 对象之间没有任何关系。 在 HMVC 中，每个 GUI 对象都可以访问其子对象，每个子对象都可以访问其父对象。
所以在每个视图中都有一个父视图。通过它可以访问它的父视图。 因为在每个控制器中都有一个父控制器，它可以通过它将事件传递给父控制器（如果事件不在其范围内。）
详细说明请点击here
新链接是this address
【讨论】：