MVC模式上的Controller是否与Martin Fowler描述的页面控制器模式相同？

Question

我在使用MVC Web应用程序(Zend Framework)方面经验丰富.当我在寻找MVC模式的每一层(即模型,视图,控制器)的更好描述时,我发现了描述类似行为的页面控制器模式,如下图所示:

http://martinfowler.com/eaaCatalog/pageController.html

MVC模式:

http://martinfowler.com/eaaCatalog/modelViewController.html

到目前为止,我能够识别的差异是,在各种应用程序上找到的MVC模式上的控制器实际上通过决定对模型实体的操作来实现业务逻辑.有时,这些操作将在存储库模式中执行,而不是直接访问模型的实体.因此,您将找到具有服务层作为业务逻辑外观的应用程序,在这种情况下,控制器很薄并且没有任何业务逻辑,只是表示逻辑,从而使用http请求数据和数据相应地确定视图由服务(或存储库)返回.

主要问题是.MVC是否实现了Page Controller模式？或MVC上的Controller类似,但有一个独特的模式？

调用一个实现业务逻辑的控制器一个PageController听起来不对,因为它不仅仅是一个"页面控制器".但是如果我们从控制器中删除业务逻辑,那么将其称为"页面控制器"是有意义的.

Answer 1

关于这个主题的一些背景.

首先,您必须了解在PHP中编写经典MVC是不可能的.在经典模式中,View正在观察模型层以查找任何更改,并在检测到此类更改时请求新数据.这是不可能的,当视图最终在行星的另一端或国际空间站上的某人电话中.

最接近经典结构的是Model2 MVC(有些人称之为"Web MVC").在此模式中,View通过服务与Model层进行交互.反过来,这些服务包括域模型的实现(如本书中所定义)和持久性抽象.View会从所述服务请求所需的所有数据.

原始MVC主题的其他流行变体是MVVM和MVP(还有HMVC模式,它与其他模式没有直接关系,是PAC的变体).正如您可能注意到的那样,M和V完全存在,但"控制结构"具有不同的名称.那是因为他们每个人都做不同的事情.

_{注意:通常,当您阅读某些使用"MVC"用于营销目的的框架时,它们与该模式无关.相反,他们只是各种质量(或缺乏)的Ruby On Rails克隆.}

与原始问题相关

简短的回答是:不.

你必须记住,PoEAA是在2002年左右发布的.事情发生了一些变化.现在,HTTP请求通常由Front Controller处理,然后Front Controller提供用于创建的参数Controller.

Controller从中实例化结构仍然很常见Model layer,但View可以在控制器内部实例化,也可以基于Response可能返回(或刚刚改变)的对象实例化Controller.

此外,虽然通常在View和之间仍然存在1:1的关系Controller,但是有时Controller会调用相同的方法来帮助生成JSON而不是HTML.这将导致控制器选择不同的视图,因为在面向JSON的情况下View,它将尝试累积一些特定数据Model layer并创建几个可能的数据结构之一.然后它编码并呈现用户(在这种情况下,最有可能是浏览器中的XRH对象).

而这些偏差仅涵盖Model2,部分MVP.

更新v2:

在Web应用程序控制器中,主要工作是将数据从请求(最好是抽象)传递到模型层,从而改变模型的状态.Controller还可以更改当前视图实例的状态.当您想要更改输出格式时,通常会发生这种情况.

视图和模型层结构的创建可以(通常 - 应该)位于Controller本身之外.

另外,请注意,这不是MVP和MVVM模式所做的,它们倾向于从"控制器"中的模型层收集数据,操纵/重构该数据,然后才将其传递给View.