MVC 混乱；梳理模型职责和结构
在过去的几周/几个月里，我对 MVC 类型架构的理解有了很大的进步（我想说），我要感谢其他 SO 爱好者；所以，谢谢！
不过，我仍然受到模型的挑战。到目前为止我已经整理并创建了；
- 一个简单的
Request对象，用于合并请求数据（GET/POST/等参数、HTTP 标头等）。 - 一个简单的
Response对象，用于收集响应数据（HTML、 JSON、HTTP 标头等） - 一个奇特的
Router，它根据正则表达式驱动的路由表解析 URI，根据Controller文件/类存在/继承来验证它们，并更新带有任何补充参数的Request对象。 - 一个简单的
Dispatcher对象，用于设置工作环境，创建并初始化必要的Controller，并向其发送Request和Response< /code> 要使用的对象。
现在是模型。
我知道，在许多（某些）情况下，模型仅仅是其关联实体（表）的表示，具有 CRUD 方法（addUser()、deleteUser() 等）在其他情况下，存在进一步的抽象级别，阻止控制器访问更细粒度的 CRUD功能，合并方法（replaceUser() - 删除、添加，然后返回用户数据）
我想知道我的最佳行动方案是什么；由于一些具体原因。
我创建了一个 Gateway 类，充当预期 Model 的代理，执行 ACL 检查（使用 Acl 对象，特殊情况“模型”）使用请求和所需的方法和参数作为检查的参数。 Controller 负责确定失败的 ACL 检查的结果（显示除该数据之外的所有内容、重定向等）。
我还引入了一个（并且我将其称为以前混合 REST/RPC，但我认为这是不正确的，因为我的资源 URI 架构不在 RPC API 层之外。 API 调用由方法、参数和请求参数组成，由特殊的 ApiController 管理，并像对 Gateway 的正常 Model 调用一样进行馈送代码>.
在我看来，促进数据访问的最佳方式是一个（呃-哦）单个巨大的模型对象，忽略任何 ORM，维护所有数据库交互方法，从而证明管理网关的简单性/ACL/模型关系。 不，这听起来是错误的。
考虑到这些架构选择，什么可能是我建模我的，嗯..模型的最佳选择？我是否真的把前面提到的设计选择的谨慎和最佳实践抛到了九霄云外？
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!
I'm still challenged by something though, the Model. So far I've sorted out and created;
- A simple
Requestobject, that consolidates request data (GET/POST/etc. params, HTTP headers, etc.) - A simple
Responseobject, that collects response data (HTML, JSON, HTTP headers, etc.) - A fancy
Routerthat resolves URIs against a regex-powered routing table, validates them based onControllerfile/class existence/inheritance, and updates theRequestobject with any supplementary parameters. - A simple
Dispatcherobject that sets up the working environment, creates and initializes the necessaryController, and sends it aRequestandResponseobject to work with.
Now the Model.
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.
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.)
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.
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.
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
也许这只是语义，但我想说模型是数据、类（以及扩展的对象）的表示，它们封装了应用程序中的实体。还有另一个缺失的部分，我将其称为持久性或数据访问层 (DAL)。 MVC 作为一种抽象并不真正关心持久性，因为使用 MVC 模式进行开发实际上不需要持久性。在（几乎？）所有使用 MVC 的 Web 应用程序中，您确实有一个数据库，因此确实需要一个持久层。持久层理解模型并使其可供控制器使用，但它实际上并不是模型的一部分。
如果将插入/检索/更新数据的概念分离到持久层中，那么剩下的就是封装应用程序实体表示的容器和关联的业务/验证逻辑。这些应该相对较小、重点突出，并且仅相互依赖于实体之间的实际数据依赖关系。这个小模型（每个实体一个）总共构成了您的应用程序的模型。您的持久层 (DAL/ORM) 也不是特别大，而是仅专注于与数据库交互以获取/存储模型。
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.
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.