我正在使用 Zend 框架的完整 MVC 功能编写一个 Web 应用程序，其中包括一个服务层、域模型和映射器。我认为我对图层的理解是正确的，但想确认一下。
上层依赖于下层，所以从顶部开始：
控制器 - 最顶层。高度依赖于它实例化、填充和呈现的视图。依赖于服务来访问模型。
查看 - 不知道控制器。有时依赖于服务或模型，例如为选择控件填充查找列表。
服务 - 向客户端提供 API，例如控制器。高度依赖模型。事实上，服务经常在模型的映射器部分和域部分之间进行调解，以便为客户完成工作。
映射器（模型，A 部分）- 对领域有深入的了解，可以操作领域对象以适应关系数据存储，并操作关系数据以创建新的领域对象。
域模型（模型，B 部分）- 包含域逻辑。域对象不知道其他层，但是由于它们需要访问其他域对象，它们可以将映射器作为“对象查找器”访问。
那个听起来是对的吗？我错过了什么？
好。在一些细节上有点错误。
MVC 中有两个主要层：
控制器不是“最顶层”。它们是表示层的一部分，它们的职责是处理用户的请求并传递提取的信息以改变模型层的状态（通过服务）和（更罕见的）当前视图。
我想说，服务是模型的“C 部分”。此外，我更喜欢将“域对象”命名为“域模型”或“模型对象”，因为它会引起额外的混淆。
并且域对象不访问数据映射器。域对象本身应该完全不知道它们是否被存储。该部分由服务处理。您可以在此答案中找到代码/api 示例。
基本上，我同意你的说法，但我会更深入一点。
控制器是视图和模型之间的中介。正如您所说，视图不知道控制器，但模型也是如此。
此外，正如您所提到的，在您的模型中，将服务层作为模型的入口点也是一个好点！
您必须始终牢记，Controller 和 View 层可能位于服务器上，而模型位于另一台服务器上。因此，您的服务充当您的业务需求和业务逻辑之间的门面。它还可以处理您的事务、错误标准化等……实际上是横向的。
对于您的域部分，我会通过将您的映射器部分分成 2 个不同的部分来扩展它。由于它是您的 DAL，您可能希望为以下内容创建类：
我的意思是，您的 BL 向您的 DAL 请求一个对象，因此您要求您的存储将其提供给您。存储有一组检索器，例如一级缓存（常规 php 数组）、二级缓存（memcached、redis、任何东西），最后是您的数据库。所以我基本上在 DAL 中有 2 个子层：一个存储类及其存储和优先级堆栈，以及在这些存储中获取的实现。
不要忘记仅使用工厂进入您的层，这样通过在其中模拟您的对象或在每个层之间添加拦截器来进行单元测试会更容易。
问候。
您忘记了 MVC 中的“M”，即模型。模型为您的视图提供了渲染它所需的信息，或者您希望在其上提交给客户的信息。控制器和视图通过您的模型交换信息。但是一个重要的细节是模型不是你的 Domail 模型