MVC 混乱；梳理模型职责和结构答案

【问题标题】：MVC Mayhem; Sorting out Model responsibility and structureMVC 混乱；梳理模型职责和结构
【发布时间】：2011-07-18 20:07:35
【问题描述】：

在过去的几周/几个月里，我对 MVC 类型架构的理解有了很大的进步（我想说），我要感谢 SO 爱好者们；所以，谢谢！

尽管如此，我仍然受到Model 的挑战。至此我已经整理并创建了；

一个简单的Request 对象，用于整合请求数据（GET/POST/等参数、HTTP 标头等）
一个简单的Response 对象，用于收集响应数据（HTML、JSON、HTTP 标头等）
一个奇特的Router，它根据正则表达式驱动的路由表解析URI，根据Controller文件/类的存在/继承来验证它们，并使用任何补充参数更新Request对象。
一个简单的Dispatcher 对象，用于设置工作环境、创建和初始化必要的Controller，并向其发送Request 和Response 对象以供使用。

现在是Model。

我了解，在许多（某些）情况下，Model 仅代表它的关联实体、表格，以及 CRUD 方法（addUser()、deleteUser() 等）。其他还有更深层次的抽象，防止控制器访问更细粒度的 CRUD 功能，合并方法（replaceUser() - 删除、添加，然后返回用户数据）

我想知道我最好的做法是什么；出于一些具体原因。

我创建了一个Gateway 类，它充当预期Model 的代理，执行ACL 检查（使用Acl 对象，特例“Model” ) 使用Request 和所需的方法和参数作为检查的参数。 Controller 负责确定 ACL 检查失败的结果（显示除该数据之外的所有数据、重定向等）

我还引入了一个（之前我将其称为混合 REST/RPC，但我认为这是不正确的，因为我的资源 URI 架构是窗外）RPC API层。 API 调用由方法、参数和请求参数组成，由特殊的ApiController 管理，并像普通的Model 调用一样被馈送到Gateway。

在我看来，促进数据访问的最佳方式是（uh-oh）单个巨大的模型对象，不考虑任何 ORM，维护所有数据库交互方法，证明简单管理网关/ACL/模型关系。 不，这听起来不对。

鉴于这些架构选择，我的最佳选择可能是对我的，嗯..Model 建模？上述的设计选择是否真的把谨慎和最佳实践抛在了脑后？

【问题讨论】：

模型应该只作为你的数据提供者的代理，并且应该只被控制器或视图访问，如果其中任何一个是错误的，那么你应该重组你的代码，使它适合这个安排。
@RobertPitt; 这基本上就是我正在做的事情（打算）。 PageController 对 Gateway 说“给我用户列表”。 Gateway 基于身份验证说“Yay”或“Nay”。如果是“Yay”，它将方法调用转发到提议的Model，并且所述方法验证并返回一个数据集，Controller 最终发送到View 进行渲染。 API 调用是一样的，除了 ApiController 而不是 PageController 并且每个方法调用都是单独请求并通过 Gateway 发送的，以 JSON 形式返回而不是 View。
我想的问题是我的页面控制器不以任何方式表示实体。在我的方法中，User_Model 旁边没有User_Controller。页面控制器比这更抽象，代表视图的意图，而不是关联的模型。
有个东西叫View Model，可以和Domain Model不同
值得阅读，可能与您的部分问题有关："... MVC as it was originally conceived about twenty years ago doesn't actually work on the web."

标签： php model-view-controller model

【解决方案1】：

也许这只是语义，但我会说模型是封装应用程序中实体的数据、类（以及对象的扩展）的表示。还有另一个缺失的部分，我将其称为持久性或数据访问层 (DAL)。 MVC 作为一种抽象并不真正关心持久性，因为您实际上不必具有持久性来使用 MVC 模式进行开发。在（几乎？）所有使用 MVC 的 Web 应用程序中，您确实有一个数据库，因此确实需要一个持久层。持久层理解模型并将其提供给控制器，但它实际上并不是模型的一部分。

如果您将插入/检索/更新数据的概念分离到持久层中，那么您剩下的就是封装应用程序实体表示的容器和相关的业务/验证逻辑。这些应该相对较小，重点突出，并且仅相互依赖于实体之间的实际数据依赖关系。这个小模型，每个实体一个，总共包含您的应用程序的模型。您的持久层 (DAL/ORM) 也不是特别大，而是仅专注于与数据库交互以获取/存储模型。

【讨论】：

感谢 tvanfosson； 为了澄清我的理解，在这种情况下，持久层是指控制器和模型之间的一层，它将模型功能聚合到一个（缺少更好的术语）可查询实体，代表应用程序状态（模型本身）在另一种意义上，我的应用程序层可以描述为； View-ViewController-ModelController-Model，View 和 Model 都接受了一层抽象胶水。
@Tomcat - 我不确定我是否理解您的描述，但我会说控制器使用持久层来存储/检索域模型，是的。我为 Web 描述 MVC 的方式是控制器响应和解释 HTTP 请求。他们从持久性介质中获取相关的领域模型，通常将它们转换为特定于视图的模型，这些模型可能包含比领域模型更多或更少的数据。他们选择要渲染的视图并将视图模型交给它。视图将数据呈现为 HTML 响应，该响应被发送回客户端。
...我会注意到，为了简单起见，我省略了一些基础架构的 guts：路由引擎、渲染引擎、模型绑定器等。
@tvanfosson; 自从我发表评论后阅读了一些内容，我意识到我的解释和理解存在错误。我想我在尝试将这一切联系在一起时遇到的主要问题是我的应用程序架构没有明确使用在许多 MVC 框架中至关重要的 CoC（Convention-over-Configuration）和架构。 server.com/user/add 和 User 数据之间没有关系。控制器“代表视图的意图”，而不是模型。不过，CoC 存在于我的应用程序中，作为使用 PHP 魔术来获取控制器名称的一种方式。
@tomcat - 您正在寻找的抽象是存储库模式，css.dzone.com/books/practical-php-patterns/…（这里是 php）和martinfowler.com/eaaCatalog/repository.html（原始）。