我是 MVC 的新手，但根据我目前所学到的知识（例如 here，由 ScottGu 编写），应该渴望“瘦控制器”而不是“胖”控制器。
再加上视图本身很薄的事实，您将在模型中获得大量代码。
所以我的问题是 - 如何将模型中的代码划分为不同的逻辑部分以降低复杂性？
您是否在模型本身中使用数据访问层和业务逻辑层（我猜它仍然会包含很多代码），还是有更好的方法来做到这一点？
谢谢。
【问题讨论】：
标签： model-view-controller design-patterns
我们使用的层是：
视图 - 尽可能薄 - 没有逻辑 - 只是显示
视图模型 - 每个视图强类型化 - 不包含实体，而只是我们想要在任何一个视图中的字段。
控制器 - 只是路由和调用到 VMS。通过路由到错误页面来处理从较低级别冒出的异常。
视图模型服务 - 创建视图模型并将其解压缩到 EF 实体中。没有数据访问逻辑。每个控制器一个 VMS。大量使用 AutoMapper 将视图模型的数据传输到实体中。
业务服务 - 数据访问的主要点。每个控制器一个 BS。根据需要使用尽可能多的存储库来完成其工作。事务范围控制器在这里。 VMS 向 BS 发出一次调用——如果需要，它将所有必要的 DB 调用包装在一个事务中。我们预计 BS 将来会调用外部服务。
存储库 - 每个（顶级）实体一个 - 为一组实体执行所有 CRUD 操作。我们的实体是大型、复杂的对象图 - 因此我们处理每个存储库的最顶层父级。
上下文 - 围绕 EF 生成的上下文的精简包装器，以便我可以模拟它们。
就 MVC 而言 - 模型部分由控制器下方的所有内容组成。
【讨论】：
以下是我通常如何划分并建议划分的方式：
型号：代表信息。永远不应包含与渲染相关的代码。不应包含发布/订阅更新的代码。不应包含读/写代码。
模型 I/O：从磁盘、网络、SQL 或其他一些后备存储读取/写入模型的代码通常应该与模型对象本身分开，以允许替代存储。
控制器基础架构：在模型之上提供一个包装器，用于向模型添加发布/订阅行为（即在模型更改时发出更改通知事件的信号）。
控制器：构造模型和视图，从存储中加载模型，在模型上注册处理程序以在更改时更新视图。在视图上注册处理程序以更新视图操作上的模型并在调用保存操作时保存/存储模型。
视图：一个或多个渲染模型的组件。
【讨论】：
您可能还想查看可以帮助尝试使控制器尽可能薄的服务层。控制器可以简单地将一些操作委托给服务层执行。通常，该层依赖于数据访问层（DAO），用于持久化您的域对象。在这种情况下，您的控制器很容易在那里协调您的控制流程。 MVC 的主要思想是关注点分离。在传统的 MVC 中，表示逻辑在控制器和视图之间共享。在 MVP（MVC 的另一种变体）的情况下，所有表示逻辑都由控制器处理。
【讨论】：
我发现一种非常有效的方法是，如您所说，将模型分离为数据服务层和业务逻辑层。业务逻辑层的基础是那些几乎直接映射到数据库表的对象。然后，数据服务层能够在进行更改或创建新对象时将这些对象直接映射到数据库中。
当我必须处理拒绝巧妙地映射到数据库中的单个表的对象时，我将创建一个外观或复合对象，业务逻辑可以通过它进行交互。这确保即使它们被业务逻辑视为一个，数据服务层仍将它们视为不同的，并且只能更新需要它的那些。
我在Mapping Objects to the Relational Model 上推荐这篇文章来帮助您入门。
【讨论】：