php view 视图 mvc,了解PHP中的MVC视图

Note: the MVC and MVC-inspired patterns are advanced constructs. They are meant to be used in codebases where ordinary object-oriented (that follows 07000 and other guidelines) code starts to become unmanageable. By introducing this pattern you would impose additional constraints, which then lets you to contain very complex applications. MVC is not meant for “hello world” apps.

让我们从头开始 …

MVC和MVC设计模式背后的核心思想是Separation of Concerns.所说的分离是双重的：

>模型层与表示层分离：

>视图与控制器分离

模型层(不是“类”或“对象”)将包含几组结构，每个处理作为业务逻辑的不同方面。主要部分是：

> domain objects：验证，业务规则

>存储抽象：对来自域对象的数据的持久性和缓存

>服务：应用程序逻辑

表示层主要由视图和控制器组成。但是他们都利用服务与模型层交互。服务为控制器提供了改变模型层的状态和视图基于该新状态收集信息的方式。

在web的上下文中，视图和控制器形成一个松散的对，因为web应用程序展示的请求 – 响应性质。

应当注意，虽然控制器可以直接改变当前视图的状态，但更常见的是这些改变通过模型来实现。改变视图直接的一个原因是，例如，而不是XML，你需要用JSON响应。

虽然也可以说，可以简单地为每种输出格式实例化不同的视图，并利用多态性。

什么是不查看？

有一个普遍的误解，视图是简单美化的模板文件。这个错误在RubyOnRails原型框架发布后变得非常受欢迎。

视图不是模板。如果你使用它们，你打破了MVC和MVC启发模式背后的核心原则。

如果你假设模板是视图，它对你的架构有很大的影响。在视图中没有UI逻辑的地方，因此你在控制器或模型层中推送UI逻辑。通常的选择是“控制器”，因为大多数人都明白UI逻辑在模型层没有地方。

本质上，这导致视图和控制器的合并。

什么是视图做？

视图的职责是处理UI逻辑。在web的上下文中，视图的目标是产生对用户的响应(其中，btw是浏览器而不是人)。

Technically it would be possible to create client side views, that user web sockets to observe model layer, but in practice it’s virtually impossible to implement. Especially not in PHP environment.

创建此响应视图从模型层获取信息，并基于收集的数据，通过将数据分发到模板和呈现或有时简单发送HTTP位置标头来组合响应。

When using 07005, the redirect part is performed by the view, not the controller as often people tend to do.

高主观位：

最近我喜欢与MVC使用以下方法进行交互：

// the factory for services was injected in constructors

$controller->{ $method.$command }($request);

$view->{ $command }();

$view->respond();

$方法是当前的* REQUEST_METHOD *，已被调整为伪类似REST的API，$命令是人们通常所说的“动作”。控制器具有用于GET和POST(另一个)请求的单独的例程。这有助于避免相同，如果在每个“行动”。

在视图中我调用两种方法。首先是一个动态调用收集数据。第二个目的是创建一些类型的响应。

Warning:I suspect that this setup contains an 07006 violation. Adopting it as your own might be a bad idea.

DRY怎么样？

正如您可能已经注意到，将视图作为实例存在一个小问题。你最终会得到重复的代码段。例如：菜单或分页。

让我们看看分页。分页包含逻辑，但是这个逻辑与模型层没有关系。该模型没有“页面”的概念。相反，这一位逻辑将驻留在表示层。但是，如果你的每一个观点都包含或继承分页，那么这将明显违反SRP(实际上还有其他一些原则)。

为了避免这个问题，你可以(和应该，imho)在您的意见中引入presentation objects。

Note: while Fowler calls them “presentation models”, I think that name just adds to the whole ‘what is model’ confusion. Therefore I would recommend to call them “presentation objects” instead.

呈现对象处理重复的逻辑块。这使得视图“更轻”，并且在一些方面开始反映来自模型层的服务的结构。

表示对象和templates之间的交互变得类似于域对象和data mappers之间的交互。

P.S. I myself am still struggling with figuring out a way how best to deal with views. This post is less of an answer and more like a snapshot of my current understanding.