MVC混乱；梳理示范责任和结构 [英] MVC Mayhem; Sorting out Model responsibility and structure

问题描述

在过去的几周/几个月中，我对MVC类型的体系结构的理解有了很大的提高(我想说)，我应该非常感谢SO爱好者.所以，谢谢你！

My understanding of MVC-type architectures over the last few weeks/months has advanced (I'd say) considerably, and I owe most of my thanks to fellow SO enthusiasts; so, thank you!

尽管如此，我仍然面临着挑战，Model.到目前为止，我已经整理并创建了

I'm still challenged by something though, the Model. So far I've sorted out and created;

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

• A simple Request object, that consolidates request data (GET/POST/etc. params, HTTP headers, etc.)
• A simple Response object, that collects response data (HTML, JSON, HTTP headers, etc.)
• A fancy Router that resolves URIs against a regex-powered routing table, validates them based on Controller file/class existence/inheritance, and updates the Request object with any supplementary parameters.
• A simple Dispatcher object that sets up the working environment, creates and initializes the necessary Controller, and sends it a Request and Response object to work with.

现在是Model.

Now the Model.

我了解到，在许多(某些)情况下，Model只是其关联实体，表的表示形式，并带有CRUD方法( addUser()，deleteUser()等).其他则有进一步的抽象层次，阻止控制器访问更精细的CRUD功能，合并方法( replaceUser()-删除，添加然后返回用户数据)

I understand that in many (some) circumstances the Model is merely representational of it's associated entity, the table, with CRUD methods (addUser(), deleteUser(), etc.) In others there are further levels of abstraction, preventing controllers from accessing finer-grain CRUD functionality, consolidating methods (replaceUser() - deletes, adds, then returns user data)

我想知道我的最佳做法是什么；出于某些特定原因.

I'm wondering what my best course of action is; for a few specific reasons.

我创建了一个Gateway类，该类充当预期的Model的代理，执行ACL检查(使用Acl对象，特殊情况为"Model" )，并使用Request和所需的方法和参数作为检查的参数. Controller负责确定ACL检查失败的结果(显示除数据外的所有内容，重定向等)

I've created a Gateway class that acts as a proxy to an intended Model, performing ACL checks (using the Acl object, a special case "Model") using the Request and desired method and arguments as parameters for the check. The Controller is responsible for determining the outcome of a failed ACL check (display all but that data, redirect, etc.)

我还介绍了(，并且以前将其称为混合REST/RPC，但是我认为这是不正确的，因为我的资源URI体系结构已经不存在了)RPC API层. API调用由方法，参数和请求参数组成，由特殊的ApiController管理，并像对Gateway的常规Model调用一样被馈送.

I've also introduced an (and I've referred to it as hybrid REST/RPC previously, but I believe that's incorrect as my resource URI architecture is out-the-window) RPC API layer. An API call consists of a method, arguments, and request parameters, is managed by the special ApiController and is fed like a normal Model call to the Gateway.

在我看来，促进数据访问的最佳方法似乎是一个( uh-oh )单个巨大的模型对象，而忽略任何ORM，该对象维护所有数据库交互方法，从而证明了简单性管理网关/ACL/模型关系. 不，听起来很错误.

It seems to me like the best way to facilitate data access, would be a (uh-oh) single enormous model object, disregarding any ORM, that maintains all database interaction methods, proving simplicity for managing the Gateway/ACL/Model relationship. No, that sounds wrong.

鉴于这些体系结构选择，为我的U..c Model建模可能是我的最佳选择?通过上述设计选择，我真的对风产生了谨慎和最佳实践吗?

Given these architectural choices, what may be my best choice for modeling my, um.. Model? Have I really thrown caution and best-practice to the wind with the aforementioned design choices?

推荐答案

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

Perhaps it's just semantics but I would say that The Model is the representation of the the data, the classes (and by extension the objects) that encapsulate the entities in your application. There's another, missing piece, which I would call the persistence or data access layer (DAL). MVC as an abstraction doesn't really concern itself with persistence because you don't actually have to have persistence to develop using the MVC pattern. In (almost?) all web applications using MVC, you do have a database and thus do need a persistence layer. The persistence layer understands The Model and makes it available to the controller, but it's not really part of the model.

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

If you separate out the concepts of inserting/retrieving/updating the data into the persistence layer, what you're left with are the containers and associated business/validation logic that encapsulate the representation of your applications entities. These should be relatively small, well-focused, and only interdependent on the actual data dependencies between your entities. This small models, one per entity, in total comprise The Model for your application. Your persistence layer (DAL/ORM), too, is not particularly large, but rather is focuses solely on interacting with the database to obtain/store the models.

这篇关于MVC混乱；梳理示范责任和结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！