我想指出的是，这个解释和建议是针对像 ASP.Net 这样的服务器端 MVC 架构的上下文，而不是像 Knockout 或 Backbone 这样的客户端框架。
All of this depends on the intention and requirements of your application.
That said, here's my suggestion for "mid scale" (not a local restaurant, and not Twitter/Facebook) web applications.
Lean Domain Modeling
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).
"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.
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.
Robust Service Layer
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).
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.
Lean Controllers
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 a View Model for the appropriate View.
Even authenticated/authorized controller actions are done via injected services/attributes.
EDIT 1:
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.
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.
EDIT 2:
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.
EDIT 3:
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.
You need to know some more about MVC before we go ahead and discuss where to put everything. Well, if you want to follow the pattern. Otherwise you can stop reading now.
The pattern is very loosely defined. There is nothing that says how the controller, view or model should look like or how they should be structured. The pattern simply states that you should separate the parts and how they should interact with each other. So let's look at bit more about what they are (my interpretation).
MVC
Model
The model can be anything. It can be a webservice, your repositories, your service classes or simply your domain models. The Model are everything that are used to get the information that you need. Consider the "Model" as a layer instead of just an single object.
Controller
The controller is a glue. It takes the information from the Model and adapts it to the view and vice versa.
View
The view should only render what the user sees.
Do note that you should not confuse the Model with View Models. Microsoft should really have named the "Model" folder "ViewModels" since that's what they are. I would not use information from the "Model" directly in the views. Failure to do so would mean that you have to change the Model if the View is changed and the other way around.
The answer
The model is not a view model but a layer. Everything in the model is used to fetch the information needed for the view. The controller takes that information and puts it into a single view model.
A single controller action might use one or several calls to the "Model" to be able to assemble the information needed by the view.
That means that your second option is the most correct when if you want to get an application which is easy to maintain and extend.
Do note that a service layer might not be needed. You can call the OR/M directly from the controllers. But if you find yourself duplicating code or getting fat controllers, simply move the logic to a service layer. Nothing but the controller will be affected by that change since you are using proper view models.
Option 2 is what's described as Fat Stupid Ugly Controllers architecture (Reference to author of this expression). This solution is generally against MVC spirit as it breaks separation of concerns.
发布评论
评论（4）
所有这一切都取决于您的应用程序的意图和要求。
也就是说，这是我对“中型”（不是本地餐馆，也不是 Twitter/Facebook）Web 应用程序的建议。
精益领域建模
干 POCO 风格的对象，最好不了解 Web 应用程序的 MVC 架构，以便尽可能与特定实现保持松散耦合。甚至可以重新打包类库以在外部应用程序中使用，例如通过 REST API WCF Web 服务）。
MVC 中的“模型”最准确地表示控制器意识到的模型，因此是用于视图的模型。
在较小的（通常是教程）应用程序中，“应用程序/域模型层”的实体模型通常与控制器发送到视图的实例化对象相同。
在较大的应用程序中，开发人员经常采用 MVVM 架构的原则并开始使用单独的视图模型对象。控制器通常调用与下面看不见的实体一起工作的中间层服务。在这种情况下，MVC 中的 M 最准确地表示视图模型。
强大的服务层
这并不意味着肥胖逻辑，而是编写良好的单一用途服务。虽然在模型外部的服务中编写业务逻辑比纯粹的“OOP”更加“程序化”，但它对松散耦合、测试和灵活部署（例如 n 层部署）有很大帮助。
在我个人的实践中，我在数据层编写服务，我认为这是我对 POCO 对象的行为建模（持久性机制、低级验证等）和更高级别的服务（业务/工作流功能）更接近 MVC 机制。
精益控制器
我确保我的控制器只是教练，因为它既不是比赛（服务）也不是玩家（实体模型）或视图模型），但只需决定谁打什么位置以及进行什么比赛。我的控制器做了两件事：
调用与实体/域模型交互的服务
为适当的视图准备视图模型。
即使经过身份验证/授权的控制器操作也是通过注入的服务/属性完成的。
编辑 1：
请记住，这并不意味着您的实体/域模型是或必须是贫乏的。欢迎 ORM、存储库和工厂、验证或状态机制。它仅意味着对于中等规模的应用程序，MVC 中的模型代表用于控制器的模型，以移交给您的视图。
希望这一点能让 Fowler 的信徒们平静下来，他们相信贫乏的数据模型是一种反模式。同时，它确实反映了比 OOP 稍微更程序化的角度，在 OOP 中，将行为包含在建模类中更加纯粹。
没有“终极真理”，但使用这种模式，您会发现构建、测试和部署应用程序很容易 - 同时保持大量的可重用性和可扩展性。
编辑 2：
也就是说，即使对于中等大小的应用程序，过度构建系统（这是一个书呆子编造的词？）也太常见了。例如，使用存储库模式包装 ORM，然后编写服务来使用存储库...所有这些都有助于分离关注点等，但如果您的项目不需要（并且不太可能很快需要）这样的东西，不要构建它。完全跳过存储库、针对 ORM 编写精简业务服务（例如查询类），甚至让控制器直接与其对话，都没有什么问题。这一切都取决于规模。
编辑3：
我想指出的是，这个解释和建议是针对像 ASP.Net 这样的服务器端 MVC 架构的上下文，而不是像 Knockout 或 Backbone 这样的客户端框架。
All of this depends on the intention and requirements of your application.
That said, here's my suggestion for "mid scale" (not a local restaurant, and not Twitter/Facebook) web applications.
Lean Domain Modeling
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).
"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.
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.
Robust Service Layer
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).
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.
Lean Controllers
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 a View Model for the appropriate View.
Even authenticated/authorized controller actions are done via injected services/attributes.
EDIT 1:
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.
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.
EDIT 2:
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.
EDIT 3:
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.
在我们继续讨论将所有内容放在哪里之前，您需要了解更多有关 MVC 的信息。好吧，如果你想遵循这个模式。否则你现在可以停止阅读。
该模式的定义非常松散。没有任何内容说明控制器、视图或模型应该是什么样子或者它们应该如何构造。该模式只是指出您应该分离各个部分以及它们应该如何相互作用。因此，让我们更多地了解它们是什么（我的解释）。
MVC
模型
模型可以是任何东西。它可以是 Web 服务、您的存储库、您的服务类或只是您的域模型。模型是用于获取您需要的信息的一切。将“模型”视为一个层而不仅仅是一个对象。
控制器
控制器是一种胶水。它从模型中获取信息并使其适应视图，反之亦然。
查看
视图应该只呈现用户看到的内容。
请注意，您不应将模型与视图模型混淆。微软确实应该将“Model”文件夹命名为“ViewModels”，因为它们就是这样的。我不会直接在视图中使用“模型”中的信息。如果不这样做，就意味着如果视图发生更改，您就必须更改模型，反之亦然。
答案
模型不是视图模型而是层。模型中的所有内容都用于获取视图所需的信息。控制器获取该信息并将其放入单个视图模型中。
单个控制器操作可能会使用对“模型”的一次或多次调用，以便能够组合视图所需的信息。
这意味着，如果您想要获得易于维护和扩展的应用程序，那么第二个选择是最正确的。
请注意，可能不需要服务层。您可以直接从控制器调用 OR/M。但是，如果您发现自己重复代码或控制器变得臃肿，只需将逻辑移至服务层即可。由于您使用的是正确的视图模型，因此除了控制器之外，其他任何东西都不会受到该更改的影响。
You need to know some more about MVC before we go ahead and discuss where to put everything. Well, if you want to follow the pattern. Otherwise you can stop reading now.
The pattern is very loosely defined. There is nothing that says how the controller, view or model should look like or how they should be structured. The pattern simply states that you should separate the parts and how they should interact with each other. So let's look at bit more about what they are (my interpretation).
MVC
Model
The model can be anything. It can be a webservice, your repositories, your service classes or simply your domain models. The Model are everything that are used to get the information that you need. Consider the "Model" as a layer instead of just an single object.
Controller
The controller is a glue. It takes the information from the Model and adapts it to the view and vice versa.
View
The view should only render what the user sees.
Do note that you should not confuse the Model with View Models. Microsoft should really have named the "Model" folder "ViewModels" since that's what they are. I would not use information from the "Model" directly in the views. Failure to do so would mean that you have to change the Model if the View is changed and the other way around.
The answer
The model is not a view model but a layer. Everything in the model is used to fetch the information needed for the view. The controller takes that information and puts it into a single view model.
A single controller action might use one or several calls to the "Model" to be able to assemble the information needed by the view.
That means that your second option is the most correct when if you want to get an application which is easy to maintain and extend.
Do note that a service layer might not be needed. You can call the OR/M directly from the controllers. But if you find yourself duplicating code or getting fat controllers, simply move the logic to a service layer. Nothing but the controller will be affected by that change since you are using proper view models.
选项 1：
你可能会认为模型==服务。
模型也是业务层。
选项 2 是贫血域模型反模式。
http://en.wikipedia.org/wiki/Anemic_domain_model
Option 1:
You could think that model == service.
Model also IS the business layer.
Option 2 is an Anemic Domain Model anti-pattern.
http://en.wikipedia.org/wiki/Anemic_domain_model
选项 2 被描述为 Fat Stupid Ugly Controllers 架构 (引用此表达式的作者）。这种解决方案通常违背 MVC 精神，因为它破坏了关注点分离。
Option 2 is what's described as Fat Stupid Ugly Controllers architecture (Reference to author of this expression). This solution is generally against MVC spirit as it breaks separation of concerns.