这些MVC图层是否正确？

Question

我正在编写一个使用Zend Framework的完整MVC功能并包含服务层，域模型和映射器的Web应用程序。我认为我对这些图层的理解是正确的，但想确认一下。

上层依赖于下面的层中，因此从顶部开始：

1. 控制器 - 最顶层。高度依赖于实例化的View，填充和渲染。依赖服务访问模型。

2. 查看 - 不了解控制器。有时候取决于服务或模型，例如填充选择控件的查找列表。

3. 服务 - 为客户端（如Controller）提供API。高度依赖于模型。事实上，服务通常会在模型的映射器和域部分之间进行调解，以便为客户完成工作。

4. 映射器（型号，A部分） - 有域成竹在胸，操纵域对象以适应关系数据存储和操纵关系数据来创建新的域对象。

5. 域模型（模型，部分B） - 包含域逻辑。然而，域对象并不知道其他图层，因为它们需要访问其他域对象，所以它们可以作为“对象查找器”访问映射器。

这听起来是对的吗？我错过了什么？

Answer 1

好吧。这是有点错误 - ish在一些细节。

有两个主要层在MVC：

• 模型层：与所有的域的业务逻辑，规则和信息涉及
• 表示层：涉及接口和交互

控制器是不是“最顶层”。它们是表示层的一部分，它们的职责是处理用户的请求并传递提取的信息以改变模型层的状态（通过服务）和（更罕见的）当前视图。

我会说，那服务是模型的“C部分”。另外，我倾向于将“域对象”命名为“域模型”或“模型对象”，因为它会导致更多的混淆。

和域对象无法访问数据映射器。域对象本身应该完全不知道它们是否存储。该部分由服务处理。您可以在this answer中找到代码/ api示例。

Answer 2

你忘了MVC的'M'，就是Model。 模型提供了您的视图，呈现它所需的信息或您希望客户提交的信息。控制器和视图通过您的模型交易信息。 但重要的细节是，模型不是你的Domail模型

Answer 3

基本上，我同意你的发言，但我会更深入一点。

控制器是视图和您的模型之间的中介。正如你所说，视图不知道控制器，但模型也是如此。

另外，在您的模型中，正如您所提到的那样，将服务层作为模型的入口点也是一个好的选择！

您必须始终保持控制器和视图图层可能在服务器上，而模型在另一个上。因此，您的服务充当您业务需求与业务逻辑之间的界限。它也可以处理你的交易，错误标准化等......实际上横向的事情。

对于您的域名部分，我会将您的映射器部分分成2个不同的部分。因为这是你的DAL，你可能希望创建类：

• 请求你的域对象，无论他们来自
• 检索你的域对象，从一个特定的位置

我的意思是，你的BL向您的DAL请求一个对象，因此您要求您的存储器将其提供给您。该存储具有一组检索器，如level1缓存（常规php数组），level2缓存（memcached，redis，任何内容），最后是数据库。所以我基本上在DAL中有两个子层：一个存储类，它有一堆存储和优先级，以及一个在这些存储中获取的实现。

不要忘记踏进你的图层只能通过工厂，这样它会更容易被嘲笑里面他们你的对象，使单元测试，或每层之间添加拦截。

问候。