model-view-controller - 将模型代码划分为 MVC 中的逻辑部分的最佳实践？哪个最好？

Question

我是 MVC 的新手，但根据我到目前为止所学到的知识(例如 here ，作者 ScottGu)应该渴望“瘦 Controller ”而不是“胖” Controller 。
再加上 View 本身就很薄的事实，你会得到 很多模型中的代码。

所以我的问题是 - 您如何将模型中的代码划分为不同的逻辑部分以降低复杂性？
您是否在模型本身中使用了数据访问层和业务逻辑层(我猜这仍然会包含大量代码)，或者是否有更好的方法来做到这一点？

谢谢你。

Answer 1

我们使用的层是:

View (使用强类型 View 模型)

Controller

查看模型服务

商务服务

存储库

(EF) 上下文

View - 尽可能薄 - 没有逻辑 - 只是显示

View 模型 - 每个 View 都是强类型的 - 不包含实体，而只包含我们在任何一个 View 中想要的字段。

Controller - 只是路由和调用 VMS。通过路由到错误页面来处理从较低级别冒泡的异常。

View 模型服务 - 创建 View 模型并将其解包到 EF 实体中。没有数据访问逻辑。每个 Controller 一个 VMS。大量使用 AutoMapper 将 View 模型的数据传输到实体中。

业务服务 - 数据访问的主要点。每个 Controller 一个 BS。根据需要使用尽可能多的存储库来完成其工作。事务范围 Controller 在这里。 VMS 对 BS 进行一次调用 - 如果需要，BS 将所有必要的 DB 调用包装在单个事务中。我们预计 BS 将来会调用外部服务。

存储库 - 每个(顶级)实体一个 - 为一组实体执行所有 CRUD 操作。我们的实体是大型、复杂的对象图 - 因此我们处理每个存储库的最顶层父级。

上下文 - 围绕 EF 生成的上下文的薄包装器，因此我可以 mock 它们。

就 MVC 而言 - 模型部分由 Controller 下方的所有内容组成。