什么是 HMVC 模式？

Posted 2023-02-23

【中文标题】什么是 HMVC 模式？

【英文标题】：What is the HMVC pattern?

【发布时间】：2011-01-16 19:57:09

【问题描述】：

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

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

【问题讨论】：

在 Kohana 论坛中就这个主题进行了讨论。您可能会发现它对您有所帮助：forum.kohanaframework.org/discussion/1681

***.com/questions/18161141/…

【参考方案1】：

Sam de Freyssinet（Kohana 开发人员之一）写了一个相当 in-depth article about HMVC，它是什么以及如何使用它。

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

【讨论】：

感谢您提供的良好链接，也可以查看此javaworld.com/jw-07-2000/jw-0721-hmvc.html

@Sithu web.archive.org/web/20160220044633/http://techportal.inviqa.com/…

链接总是会死掉的！发布内容而不是链接。

【参考方案2】：

我目前正在开发自己的名为 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 中的 H 具有误导性（没有真正的层次结构）。跨度>

是的，你说得很好。实际上，我在 Confoo 2011 上关于 Alloy 的一次演示中分享了这个观点，并给它起了另一个名字——“嵌套 MVC”。它在 Slideshare 上，幻灯片 #20：slideshare.net/vlucas/alloy-hmvc-php-framework

HMVC 将如何处理从模块树中多次返回的需求？例如整理head/body/footer 内容、JS/Css 依赖和模块之间的相互关系。事件？挂钩？单例页面框架？结构化返回对象？

这个答案是***的副本：/ en.wikipedia.org/wiki/…

@EricG 看起来有人复制了我在这里给出的答案，然后将其添加到***（不是我）。检查***文章底部的“参考”部分 - 它链接回此评论。

【参考方案3】：

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

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

【参考方案4】：

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

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

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

[2011 年 4 月、2012 年 3 月更新：针对 cme​​ts 扩展了答案。]

【讨论】：

能够将“内部”服务请求转换为“外部”请求意味着您可以在需要时更轻松地进行横向扩展，即将一些应用程序模块移动到它们自己的服务器上。

是的，尝试使用它和不使用它来实现一个内部 Web 服务，看看它是否真的“没有那么重要”。

@Kemo 我认为这是一个很好的架构，我只是觉得这个名字令人困惑，它暗示 Kohana 正在做一些特别不寻常的事情。

我不确定您的回答是否有帮助。你不是在回答这个问题，只是抱怨这个名字，而且没有必要（这很好）。

【参考方案5】：

HMVC 是分层模型视图控制器。在普通 MVC 中，每个 GUI 对象都有自己的 MVC。但是与 HMVC 不同，父 GUI 对象和子 GUI 对象之间没有任何关系。 在 HMVC 中，每个 GUI 对象都可以访问其子对象，每个子对象都可以访问其父对象。

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

详细说明请点击here

新链接是this address

【讨论】：

一个好的答案的标志不仅仅是没有其他信息或上下文的链接。请您扩展您的答案并总结链接帖子的相关部分？

@Sanjay，您有什么理由将链接的目的地从 HMVC 文章更改为关于 gwt for mobile 状态的文章？

@Koch..我没有更改链接...即使我不知道是谁更改了它...顺便说一句，我将其链接到原始链接。