blocks|key|3358993|text|业务逻辑真的应该在模型中。你的目标应该是胖的模型，瘦的控制器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3358994|例如，而不是拥有：|3358995|public+interface+IOrderService{
++++int+CalculateTotal(Order+order);
}|code-block|syntax|javascript|3358996|我宁可：|3358997|public+class+Order{
++++int+CalculateTotal(ITaxService+service){...}++++++++
}|3358998|这假设税是由外部服务计算的，并要求您的模型了解外部服务的接口。|3358999|这会让你的控制器看起来像这样：|3359000|public+class+OrdersController{
++++public+OrdersController(ITaxService+taxService,+IOrdersRepository+ordersRepository){...}

++++public+void+Show(int+id){
++++++++ViewData["OrderTotal"]+=+ordersRepository.LoadOrder(id).CalculateTotal(taxService);
++++}
}|3359001|或者类似的东西。|3359002|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|13|8|@]|9|@]|A|$G|H]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

Business logic should really be in the model. You should be aiming for fat models, skinny controllers.

For example, instead of having:

<pre><code>public interface IOrderService{
 int CalculateTotal(Order order);
}
</code></pre>

I would rather have:

<pre><code>public class Order{
 int CalculateTotal(ITaxService service){...} 
}
</code></pre>

This assumes that tax is calculate by an external service, and requires your model to know about interfaces to your external services.

This would make your controller look something like:

<pre><code>public class OrdersController{
 public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

 public void Show(int id){
 ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
 }
}
</code></pre>

Or something like that.

blocks|key|3359146|text|这是一个很有趣的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3359147|我认为有趣的是，在真正将“业务逻辑”完全放在模型中的意义上，大量示例MVC应用程序实际上并没有遵循MVC范例。Martin+Fowler指出，MVC不是四人帮意义上的模式。相反，如果程序员要创建一个玩具应用程序以外的东西，就必须向其添加模式。|3359148|因此，简而言之，“业务逻辑”确实不应该存在于控制器中，因为控制器增加了处理视图和用户交互的功能，而我们希望创建的对象只有一个目的。|3359149|一个更长的答案是，在将逻辑从控制器移动到模型之前，您需要在模型层的设计中投入一些想法。也许您可以使用REST处理所有应用程序逻辑，在这种情况下，模型的设计应该相当清晰。如果没有，你应该知道你将使用什么方法来防止你的模型变得臃肿。|3359150|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

This is a fascinating question. 

I think that its interesting that a large number of sample MVC applications actually fail to follow the MVC paradigm in the sense of truly placing the "business logic" entirely in the model. Martin Fowler has pointed out that MVC is not a pattern in the sense of the Gang Of Four. Rather, it is paradigm that the programmer must add patterns to if they are creating something beyond a toy app. 

So, the short answer is that "business logic" should indeed not live in the controller, since the controller has the added function of dealing with the view and user interactions and we want to create objects with only one purpose. 

A longer answer is that you need to put some thought into the design of your model layer before just moving logic from controller to model. Perhaps you can handle all of app logic using REST, in which case the model's design should be fairly clear. If not, you should know what approach you are going to use to keep your model from becoming bloated.

blocks|key|3359173|text|你可以看看这篇由Stephen+Walther写的很棒的教程，它展示了Validating+with+a+Service+Layer。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3359174|3359175|了解如何将验证逻辑从控制器操作移到单独的服务层中。在本教程中，Stephen+Walther解释了如何通过将服务层与控制器层隔离来保持关注点的清晰分离。|blockquote|3359176|3359177|entityMap|0|LINK|mutability|MUTABLE|url|http://www.asp.net/mvc/tutorials/validating-with-a-service-layer-cs^0|Z|V|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|V|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

You can check this awesome tutorial by Stephen Walther that shows <a href="http://www.asp.net/mvc/tutorials/validating-with-a-service-layer-cs" rel="noreferrer">Validating with a Service Layer</a>.

<blockquote>
 Learn how to move your validation
 logic out of your controller actions
 and into a separate service layer. In
 this tutorial, Stephen Walther
 explains how you can maintain a sharp
 separation of concerns by isolating
 your service layer from your
 controller layer.
</blockquote>

blocks|key|361965|text|我喜欢Microsoft+Patterns+&+Practices展示的图表。我相信这句格言：“一张图片胜过千言万语”。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|361966|​|361967|📷|atomic|361968|361969|entityMap|0|LINK|mutability|MUTABLE|url|https://msdn.microsoft.com/en-us/library/hh404093.aspx|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/2b5c2c2134adf10236fa2f06ebbaf750.jpeg|imageAlt^0|3|U|0|0|0|0|1|1|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|12|8|@]|9|@$A|13|B|14|1|15]]|C|$]]|$1|I|3|E|5|6|7|16|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|17|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]|R|$5|S|N|T|C|$U|V|W|-4]]]]

I like the diagram presented by <a href="https://msdn.microsoft.com/en-us/library/hh404093.aspx" rel="noreferrer">Microsoft Patterns &amp; Practices</a>. And I believe in the adage 'A picture is worth a thousand words'.

<img src="https://i.stack.imgur.com/VqqTF.jpg" alt="Diagram shows architecture of MVC and business sevices layers">

blocks|key|3359338|text|业务逻辑不应该包含在控制器中。控制器应该尽可能的紧凑，最好遵循下面的模式：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3359339|3359340|Find+domain+entity|ordered-list-item|3359341|Action域entity|3359342|准备用于查看/返回结果的数据|3359343|3359344|此外，控制器可以包含一些应用程序逻辑。|3359345|那么我应该把我的业务逻辑放在哪里呢？在模型中。|3359346|什么是Model？这是一个很好的问题。请参阅Microsoft+Patterns+and+Practices+article+(向AlejandroR致敬，以获得出色的查找)。这里有三类模型：|offset|length|3359347|3359348|View模型：这只是一个数据包，其中包含基本字段Fat模型：带有业务逻辑的Fat模型，操作单个或多个数据实体(即，处于给定状态的实体A而不是实体B)|unordered-list-item|style|BOLD|3359349|Data模型：存储感知模型，单个实体中包含的逻辑仅与该实体相关)|3359350|3359351|当然，MVC是一种不同类型的范例。我在这里描述的是MVC只占用顶层，通过this+article+on+Wikipedia|3359352|在简单的场景中，MVC可能代表系统的主要设计，直接到达数据库；但是，在大多数场景中，MVC中的控制器和模型对服务或数据层/层具有松散的依赖关系。这一切都是关于客户端-服务器体系结构的|3359353|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/hh404093.aspx|1|http://en.wikipedia.org/wiki/Multitier_architecture#Comparison_with_the_MVC_architecture^0|0|0|0|0|0|0|0|0|M|14|0|0|0|0|6|0|0|6|0|0|10|P|1|0|0^^$0|@$1|2|3|4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1H|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1I|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|1J|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1L|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1M|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1N|8|@]|9|@$Q|1O|R|1P|1|1Q]]|A|$]]|$1|S|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|1S|8|@$Q|1T|R|1U|W|X]]|9|@]|A|$]]|$1|Y|3|Z|5|V|7|1V|8|@$Q|1W|R|1X|W|X]]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1Z|8|@]|9|@$Q|20|R|21|1|22]]|A|$]]|$1|13|3|14|5|6|7|23|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|24|8|@]|9|@]|A|$]]]|16|$17|$5|18|19|1A|A|$1B|1C]]|1D|$5|18|19|1A|A|$1B|1E]]]]

Business Logic should not be contained in controllers. Controllers should be as skinny as possible, ideally follow the patter:

<ol>
<li>Find domain entity</li>
<li>Act on domain entity</li>
<li>Prepare data for view / return results</li>
</ol>

Additionally controllers can contain some application logic.

So where do I put my business logic? In Model.

What is Model? Now that's a good question. Please see <a href="http://msdn.microsoft.com/en-us/library/hh404093.aspx">Microsoft Patterns and Practices article</a> (kudos to AlejandroR for excellent find). In here there are three categories of models:

<ul>
<li>View Model: This is simply a data bag, with minimal, if any, logic to pass data from and to views, contains basic field validation.</li>
<li>Domain Model: Fat model with business logic, operates on a single or multiple data entities (i.e. entity A in a given state than action on entity B)</li>
<li>Data Model: Storage-aware model, logic contained within a single entity relates only to that entity (i.e. if field a then field b)</li>
</ul>

Of course, MVC is a paradigm that comes in different varieties. What I describe here is MVC occupying top layer only, vide <a href="http://en.wikipedia.org/wiki/Multitier_architecture#Comparison_with_the_MVC_architecture">this article on Wikipedia</a>

<blockquote>
 Today, MVC and similar model-view-presenter (MVP) are Separation of Concerns design patterns that apply exclusively to the presentation layer of a larger system. In simple scenarios MVC may represent the primary design of a system, reaching directly into the database; however, in most scenarios the Controller and Model in MVC have a loose dependency on either a Service or Data layer/tier. This is all about Client-Server architecture
</blockquote>

blocks|key|3146560|text|如果您使用依赖项注入器，您的业务逻辑将转到依赖项注入器，因此您将获得整洁干净的控制器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3146561|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If u use Dependency Injectors your business logic will go to them and hence you will get neat and clean controllers.

Derik Whitaker posted an <a href="http://devlicio.us/blogs/derik_whittaker/archive/2008/10/22/how-is-interacting-with-your-data-repository-in-your-controller-different-or-better-than-doing-it-in-your-code-behind.aspx" rel="noreferrer">article</a> a couple of days ago that hit a point that I've been curious about for some time: should business logic exist in controllers?

So far all the ASP.NET MVC demos I've seen put repository access and business logic in the controller. Some even throw validation in there as well. This results in fairly large, bloated controllers. Is this really the way to use the MVC framework? It seems that this is just going to end up with a lot of duplicated code and logic spread out across different controllers.

ASP.NET MVC - Should business logic exist in controllers?

数据库

服务器

Derik Whitaker几天前发布了一篇，这篇文章触及了我一段时间以来一直好奇的观点：应该在控制器中存在业务逻辑吗？到目前为止，我见过的所有ASP.NET MVC演示都将存储库访问和业务逻辑放在了控制器中。有些人甚至还在其中加入了验证。这会导致相当大的、臃肿的控制器。这真的是使用MVC框架的方式吗？似乎这只会导致大...

问ASP.NET MVC -业务逻辑应该存在于控制器中吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ASP.NET MVC -业务逻辑应该存在于控制器中吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ASP.NET MVC -业务逻辑应该存在于控制器中吗？
EN