阅读Kohana的文档，我发现3.0版本的主要区别在于它遵循HMVC模式，而不是像2.x版本那样遵循MVC模式。Kohana的文档中有关此内容的页面以及Wikipedia上的页面并未真正给我一个清晰的主意。
那么问题来了：HMVC模式是什么，它与MVC有何不同？
Answers:
Samana Freyssinet（Kohana开发人员之一）写了一篇关于HMVC的相当深入的文章，它是什么以及如何使用它。
链接已死：新链接-https://web.archive.org/web/20160214073806/http: //techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/
我目前正在开发自己的名为Alloy的PHP 5.3 HMVC框架。由于我在HMVC上进行了大量投资并出售，因此我想我可以提供不同的观点，也许可以更好地解释为什么应使用HMVC及其带来的好处。
使用HMVC架构的最大实际好处是内容结构的“小部件化”。例如注释，等级，Twitter或博客RSS feed显示或电子商务网站的购物车内容显示。本质上，这是一条内容，需要根据主HTTP请求的上下文在多个页面上显示，甚至可能在不同的位置显示。
传统的MVC框架通常无法为这些类型的内容结构提供直接的答案，因此人们通常最终会使用自定义助手来复制和切换布局，创建自己的窗口小部件结构或库文件，或者从主要请求中提取不相关的数据控制器以推入视图并局部渲染。这些都不是特别好的选择，因为呈现特定内容或加载所需数据的责任最终会泄漏到多个区域并在使用位置重复。
HMVC，或者特别是将子请求分派给Controller来处理这些职责的能力是显而易见的解决方案。如果您考虑自己在做什么，它将完全适合Controller结构。您需要加载有关注释的一些数据，并以HTML格式显示它们。因此，您将带有一些参数的请求发送到注释Controller，它与Model交互，选择一个View，然后View显示内容。唯一的不同是您希望注释以嵌入式方式显示，用户正在查看的博客文章下方，而不是一个完全独立的完整注释页面（尽管使用HMVC方法，您实际上可以使用相同的控制器来处理内部和外部请求，并且“俗话说：“两只鸟和一块石头”。在这方面，HMVC实际上只是努力提高代码模块化，可重用性以及保持更好的关注点分离的自然产物。这是HMVC的卖点。
因此，尽管Sam de Freyssinet关于HMVC扩展的TechPortal文章值得思考，但并不是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月：根据评论扩展了答案。]
HMVC是分层模型视图控制器。在常规MVC中，每个GUI对象都有其MVC，但是与HMVC不同，父GUI对象和子GUI对象之间没有任何关系。在HMVC中，每个GUI对象都可以访问其子对象，而每个子对象都可以访问其父对象。
因此在每个视图中都有一个父视图，通过它可以访问父视图。对于每个控制器中都有一个父控制器，通过它可以将事件传递给父控制器（如果事件不在其范围内）。
详情请点击这里
新链接是这个地址