胖模型/瘦控制器与服务层[关闭]

我多年来一直使用 .Net 开发企业应用程序 我的应用程序通常有一个域模型，其中包含映射到 SQL DB 表的实体。 我使用存储库模式、依赖注入和服务层。

最近，我们开始从事 MVC 3 项目，并且我们争论了在哪里放置哪个逻辑。 我遇到了瘦控制器/FAT 模型架构，并且想知道服务层如何适应

选项 1 - 模型与服务对话

控制器很薄，调用模型上的方法。这些模型“知道”如何从数据库加载自身并与存储库或服务通信。 例如。 customerModel 有一个 Load(id) 方法，可以加载客户和一些子对象，例如 GetContracts()。

选项 2 - 控制器与服务对话

控制器要求服务检索模型对象。加载/存储等逻辑位于服务层。该模型是一个纯实体模型，只有数据。

为什么选项 1 是更好的选择，尤其是当我们谈论企业应用程序时，我的经验告诉我要分离关注点，使模型和控制器尽可能精简，并使用专门的服务来执行业务逻辑（包括数据库交互）

感谢您对优质资源的所有建议和参考。

所有这一切都取决于您的应用程序的意图和要求。

也就是说，这是我对“中型”（不是本地餐馆，也不是 Twitter/Facebook）Web 应用程序的建议。

1. 精益领域建模

   干燥的 POCO 风格对象，最好不了解 Web 应用程序的 MVC 架构，以便尽可能与特定实现保持松散耦合。甚至可以重新打包类库以在外部应用程序中使用，例如通过 WCF Web 服务的 REST API ）。

   MVC中“模型”最准确的意思是控制器知道的模型因此用于视图的模型.

   在较小的（通常是教程）应用程序中，“应用程序/域模型层”的实体模型通常与控制器发送到视图的实例化对象相同。

   在较大的应用程序中，开发人员通常采用 MVVM 架构的原则并开始使用单独的视图模型对象。控制器通常调用与下面看不见的实体一起工作的中间层服务。在这种情况下，MVC 中的 M 最准确地表示视图模型。

2. 强大的服务层

   这并不意味着obese逻辑，但编写良好的单一目的服务。虽然在模型外部的服务中编写业务逻辑比纯粹的“OOP”更加“程序化”，但它对松散耦合、测试和灵活部署（例如 n 层部署）有很大帮助。

   在我个人的实践中，我在数据层编写服务，我认为这是我对 POCO 对象的行为建模（持久性机制、低级验证等），以及更接近于更高级别的服务（业务/工作流功能） MVC 机制。

3. 精益控制器

   我确保我的控制器只是教练，因为它既不是play（服务）或player（实体模型或视图模型），但只是决定谁打什么位置以及打什么比赛。我的控制器做了两件事：

   1. 调用与实体/域模型交互的服务

   2. 为适当的视图准备视图模型。

   即使经过身份验证/授权的控制器操作也是通过注入的服务/属性完成的。

EDIT 1:

请记住，这并不意味着您的实体/域模型是或必须是贫乏的。欢迎 ORM、存储库和工厂、验证或状态机制。它仅意味着对于中等规模的应用程序，Model在MVC中代表用于控制器的模型，将其移交给您的视图.

希望这一点能让福勒使徒们平静下来，他们相信贫乏的数据模型成为一个反模式。同时，它does反映了比 OOP 稍微更程序化的角度，在 OOP 中将行为包含在建模类中更加纯粹。

没有“终极真理”，但使用这种模式，您会发现构建、测试和部署应用程序很容易 - 同时保持大量的可重用性和可扩展性。

EDIT 2:

也就是说，即使对于规模适中的应用程序，过度设计系统（这是书呆子们编造的一个词？）也太常见了。例如，使用存储库模式包装 ORM，然后编写服务来使用存储库...所有这些都有助于分离关注点等，但如果您的项目不需要（并且不太可能）soonrequire) 这样的东西，不要构建它。完全跳过存储库、针对 ORM 编写精简业务服务（例如查询类），甚至让控制器直接与其对话，都没有什么问题。这一切都取决于规模。

EDIT 3:

我想指出的是，此解释和建议适用于 ASP.Net 等服务器端 MVC 架构的上下文，而不适用于 Knockout 或 Backbone 等客户端框架。