关闭。这个问题是opinion-based .它目前不接受答案。
想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.
8年前关闭。
Improve this question
多年来，我一直在使用 .Net 开发企业应用程序
我的应用程序通常有一个域模型，其中包含映射到 SQL 数据库表的实体。
我使用存储库模式、依赖注入(inject)和服务层。
最近我们开始研究 MVC 3 项目，我们争论了把哪个逻辑放在哪里。
我遇到了瘦 Controller /FAT 模型架构，想知道服务层如何适应
选项 1 - 模型与服务对话
Controller 很薄，在模型上调用方法。模型“知道”如何从数据库中加载自己并与存储库或服务通信。
例如。 customerModel 有一个 Load(id) 方法并加载客户和一些子对象，例如 GetContracts()。
选项 2 - Controller 与服务对话
Controller 要求服务检索模型对象。加载/存储等逻辑在服务层。该模型是纯实体模型，仅包含数据。
为什么选项 1 是一个更好的选择，尤其是当我们谈论企业应用程序时，我的经验告诉我要分离关注点，保持模型和 Controller 尽可能薄，并有专门的服务来处理业务逻辑(imcl。数据库交互)
感谢所有建议和对良好资源的引用。
最佳答案
所有这些都取决于您的应用程序的意图和要求。
也就是说，这是我对“中等规模”(不是本地餐厅，也不是 Twitter/Facebook)Web 应用程序的建议。
干 POCO 样式的对象，最好对 Web 应用程序的 MVC 架构一无所知，以尽可能与您的特定实现保持松散耦合。甚至可以重新打包类库以在外部应用程序中使用，例如通过 WCF Web 服务的 REST API )。
MVC 中的“模型”最准确地表示 Controller 知道的模型，因此是用于 View 的模型。
在较小的(通常是教程)应用程序中，“应用程序/域模型层”的实体模型通常是 Controller 发送到 View 的相同实例化对象。
在较大的应用程序中，开发人员通常采用 MVVM 架构的原则并开始使用单独的 View 模型对象。 Controller 通常调用与下面看不见的实体一起工作的中间层服务。在这种情况下，MVC 中的 M 最准确的意思是 View Model。
这并不意味着肥胖的逻辑，而是精心编写的单一用途服务。虽然在模型之外的服务中编码业务逻辑比纯粹的“OOP”更“程序化”，但它对松散耦合、测试和灵活部署(例如 n 层部署)有很大帮助。
在我个人的实践中，我在数据层对服务进行编码，我认为我对 POCO 对象的行为建模(持久性机制、低级别验证等)和更高级别的服务(业务/工作流功能)更接近于MVC 机制。
我确保我的 Controller 只是教练，因为它既不是游戏(服务)也不是玩家(实体模型或 View 模型)，而只是决定谁扮演什么位置以及做什么游戏。我的 Controller 做两件事:
甚至经过身份验证/授权的 Controller 操作也是通过注入(inject)的服务/属性完成的。
编辑 1:
请记住，这并不意味着您的实体/域模型是或必须是贫血的。欢迎使用 ORM、存储库和工厂、验证或状态机制。这仅意味着对于中等规模的应用程序，MVC 中的模型代表了 Controller 的模型，以移交给您的 View 。
希望这一点能让那些相信贫血数据模型是反模式的 Fowler 使徒们平静下来。同时，它确实反射(reflect)了比 OOP 稍微更程序化的角度，后者更纯粹地将行为包含在建模类中。
没有“终极真理”，但使用这种模式，您会发现构建、测试和部署应用程序很容易——同时保持大量的可重用性和可伸缩性。
编辑 2:
也就是说，即使对于规模适中的应用程序，过度架构( Nerd 组成的词？)系统也太常见了。例如，用存储库模式包装 ORM，然后编写服务以使用存储库......所有这些都有助于关注点分离等，但是如果您的项目不需要(并且不太可能很快需要) 这样的东西，不要 build 它。一起跳过存储库，针对 ORM 编写瘦业务服务(例如查询类)，甚至让您的 Controller 直接与它对话都没有错。这一切都取决于规模。
编辑 3:
我想指出，这个解释和建议是针对像 ASP.Net 这样的服务器端 MVC 架构的上下文，而不是针对像 Knockout 或 Backbone 这样的客户端框架。
关于asp.net-mvc - 胖模型/瘦 Controller 与服务层，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8735466/