阅读Kohana的文档,我发现3.0版本的主要区别在于它遵循HMVC模式而不是版本2.x的MVC.Kohana的文档和维基百科上的这个页面并没有真正给我一个清晰的想法.
那么问题:什么是HMVC模式以及它与MVC的区别？
Van*_*cas 58
我目前正在开发自己的PHP 5.3 HMVC框架,名为Alloy.由于我在HMVC上大量投资和销售,我认为我可以提供不同的观点,或许可以更好地解释为什么应该使用HMVC及其带来的好处.
使用HMVC架构的最大实际好处是内容结构的"小部件化".一个示例可以是评论,评级,Twitter或博客RSS提要显示,或电子商务网站的购物车内容的显示.它本质上是一段内容,需要跨多个页面显示,甚至可能在不同的地方显示,具体取决于主HTTP请求的上下文.
传统的MVC框架通常不能为这些类型的内容结构提供直接的答案,因此人们通常最终会使用自定义帮助程序复制和切换布局,创建自己的窗口小部件结构或库文件,或者从主要请求中提取不相关的数据控制器推送到View并在局部渲染.这些都不是特别好的选择,因为呈现特定内容或加载所需数据的责任最终会泄漏到多个区域并在所使用的位置重复.
HMVC,或者特别是向Controller发送子请求以处理这些责任的能力是显而易见的解决方案.如果你考虑一下你正在做什么,它就完全符合Controller结构.您需要加载一些有关注释的数据,并以HTML格式显示它们.因此,您向注释控制器发送请求,其中包含一些参数,它与模型交互,选择视图,视图显示内容.唯一的区别是您希望在用户正在查看的博客文章下方显示内联的评论,而不是完全独立的完整评论页面(尽管使用HMVC方法,您实际上可以使用相同的控制器同时提供内部和外部请求并"杀死"一石二鸟",俗话说".在这方面,HMVC实际上只是努力增加代码模块化,可重用性和保持更好的关注点分离的自然副产品.这是HMVC的卖点.
因此,虽然Sam de Freyssinet的关于使用HMVC扩展的TechPortal文章很有意思,但使用HMVC框架的人中90%以上的人不会从中获得真实,实用的日常好处.
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描述了相同的概念" 子请求 "),事实上这个名称似乎用词不当:没有特别的要求或需要请求形成一个层次结构(除了每个命令性程序的标准调用图之外); 例如,请求可以很容易地递归.
[ 2011年4月更新,2012年3月:根据回复扩大回答.]