高脂模型/薄控制器与服务层 [英] Fat model / thin controller vs. Service layer
问题描述
我一直在开发多年使用的.Net企业级应用
我的应用程序通常包含实体映射到SQL数据库表的域模型。
我使用的是库模式，依赖注入和服务层。
I have been developing enterprise applications for many years using .Net My apps usually have a domain model containing entities mapping to SQL DB tables. I use a Repository pattern, Dependency injection and a service layer.
最近，我们开始对MVC 3项目的工作，我们有一个辩论在哪里把它的逻辑。
我来到翻过薄控制器/ FAT模式架构，并想知道服务层将如何适应
Recently we started working on MVC 3 projects and we had a debate where to put which logic. I came accross thin Controller / FAT Model architecture and was wondering how the service layer would fit in
控制器薄，呼吁模型的方法。该机型知道如何从DB加载themselfs聊到仓库或服务。
例如。 customerModel有一个负载（ID）方法，并加载客户和一些子对象像GetContracts（）。
Controller is thin, calls methods on the models. The models "know" how to load themselfs from the DB and talk to repositories or services. E.g. customerModel has a Load(id) method and loads the customer and some child objects like GetContracts().
控制器要求服务检索模型对象。装载的逻辑/存储等是在服务层。该模型与数据的纯实体模型而已。
Controller asks Services to retrieve model objects. The logic of loading / storing etc. Is in the service layer. The model is a pure entity model with data only.
为什么会选择1是一个更好的选择，特别是当我们谈论企业applictions我的经验告诉我，分离的担忧，保持模型和控制器尽可能的薄，并有专门的服务做的业务逻辑（IMCL该数据库交互）
Why would option 1 be a better choice especially when we talk about enterprise applictions my experience tells me to separate concerns, keep models AND Controllers as thin as possible and have specialized services doing the Business logic (imcl. The DB interaction)
感谢所有建议和参考，以良好的资源。
Thanks for all advices and references to good resources.
推荐答案
所有这一切都依赖于意图和应用程序的需求。
All of this depends on the intention and requirements of your application.
这是说，这里是我的建议为中等规模（而不是当地的餐厅，而不是微博/ Facebook）的Web应用程序。
That said, here's my suggestion for "mid scale" (not a local restaurant, and not Twitter/Facebook) web applications.
-
精益领域建模
干POCO样式对象，preferably无知到Web应用程序仍然是松散从特定的实现加上作为possible.perhaps甚至类库重新包装，能够在外部应用程序中使用的MVC架构，说REST通过WCF Web服务API）。
Dry POCO style objects, preferably ignorant to the MVC architecture of your web application to remain as loosely coupled from your particular implementation as possible.perhaps even class library repack-able for use in an external application, say a REST API via a WCF Web Service).
在MVC模式最准确地指的模型中的控制器意识到的，因而<EM>模型用于查看的。
"Model" in MVC most accurately means the model the Controller is aware of and thus the the model intended for the View.
在较小的（通常教程）应用程序的应用程序/域模型层的实体模型往往是相同的实例化的对象控制器船开了一个视图。
In smaller (often Tutorial) applications the entity models of your "Application/Domain Model Layer" are often the same instantiated objects the controller ships off to a View.
在较大的应用程序开发人员经常使用MVVM架构的原则，并开始使用独立的视图模型对象。该控制器经常打电话与下面的看不见的实体合作中间层服务。在这种情况下，MVC中的M个最准确地表示视图模型。
In larger applications developers often employ the tenets of MVVM architecture and begin using separate View Model objects. The controllers often call middle-tier services that work with the unseen entities below. In this scenario, the M in MVC most accurately means the View Model.
强大的服务层
这并不意味着的肥胖的逻辑，但写得很好的单一目的服务。而在模型的外部服务编码业务逻辑是一个比较程序比它是纯粹的面向对象，它帮助了很多松耦合，测试和灵活的部署（例如n层部署）。
This does not mean obese logic, but well-written single purpose services. While coding your business logic in services outside of the model is a bit more "procedural" than it is pure "OOP", it helps a lot with loose coupling, testing, and flexible deployment (ex. n-tier deployment).
在我个人的实践中，我code服务无论是在数据层，我认为我的POCO对象（持久化机制，低级别验证等）的行为建模，以及更高层次的服务（企业倒下/工作流功能）高达接近MVC机制。
In my personal practice, I code services both down at the data layer, which I consider my behavioral modeling of the POCO objects (persistence mechanics, low level validation, etc.), and higher level services (business/workflow function) up closer to the MVC mechanics.
精益控制器
我要确保我的控制器仅仅是教练的，因为它既不的播放的（服务）或播放的（实体模型或视图模型），而只是决定谁扮演什么样的地位，并做出怎样的发挥。我的控制器做两件事情：
I make sure my controller is merely the coach, in that it is neither the play (services) or the player (entity model or view model), but simply decides who plays what position and what play to make. My controllers do two things:
-
这与实体/域模型互动呼叫服务
Call services that interact with the entity/domain Models
prepare为适当的查看视图模型。
Prepare a View Model for the appropriate View.
即使身份验证/授权的控制器操作是通过注射服务做得/属性。
Even authenticated/authorized controller actions are done via injected services/attributes.
编辑1：
请记住，这并不意味着你的实体/域模型，或者必须是贫血。奥姆斯，仓库和工厂，验证或国家机制是欢迎的。它仅用于在MVC重新presents的模型意味着控制器，用手给您的视图的
Keep in mind, that this does not mean your Entity/Domain Model is or must be anemic. ORMs, repositories and factories, validation or state mechanics are welcome. It only means for applications of moderate scale, the Model in MVC represents the model meant for the controller, to hand off to your View.
希望这一点会平静福勒使徒谁相信的贫血数据模型的是一个的反模式的。与此同时，它的确实的反映比OOP稍微程序的角度它是更纯粹的包括在建模类的行为。
Hopefully this point will calm Fowler apostles who believe the anemic data model to be an anti-pattern. At the same time, it does reflect a slightly more procedural angle than OOP where it is more pure to include behavior in the modeled classes.
有没有终极真理，但使用这种模式，你会发现很容易构建，测试和部署应用程序 - 同时保持大量的可重用性和可扩展性的
There is no "ultimate truth", but using this pattern you'll find it easy to build, test, and deploy your applications - while maintaining a lot of re-usability and scalability.
编辑2：
这是说，即使是中等规模的应用，在架构设计（一个字书呆子组成？）的系统是非常太常见了。例如，包装一个ORM与存储库模式，然后写服务使用存储库......这一切都是很好的关心，这样的分离，但如果你的项目不需要（而且也不是很容易的尽快的要求）这样的事情，不建了。没有什么错跳过库一起，书写细商务服务（例如，查询类）针对ORM，甚至直接有你的控制器的谈话吧。这一切都取决于规模。
That said, even for modestly sized applications, over architecting (that a word nerds made up?) a system is much too common. For instance, wrapping an ORM with a repository pattern, and then writing services to use the repository... all this is good for separation of concern and such, but if your project doesn't require (and is not very likely to soon require) such things, don't build it. There is nothing wrong with skipping the repository all together, writing thin business services (ex. query classes) against an ORM, or even having your controller talk directly to it. It all depends on scale.
修改3：
我想指出，这个解释和建议对于像ASP.Net服务器端的MVC架构的情况下，没有像淘汰赛或骨干克伦特端框架。
I wanted to note that this explanation and advice is for the context of server-side MVC architecture like ASP.Net, not for clent-side frameworks like Knockout or Backbone.
这篇关于高脂模型/薄控制器与服务层的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
