blocks|key|1675776|text|您的业务逻辑应该封装在业务对象中-如果您有一个Order对象(您确实是这样做的，不是吗？)，并且一个业务规则规定当订单完成时应该发送一封电子邮件，那么您的Fulfill方法(或者，如果更合适的话，是IsFulfilled的设置器)应该触发该操作。我可能拥有将业务对象指向应用程序的适当电子邮件服务的配置信息，或者更一般地指向“通知程序”服务的配置信息，以便在必要时添加其他通知类型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1675777|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|$]]

Your business logic should be encapsulated in business objects - if you have an Order object (and you do, don't you?), and a business rule states that an email should be sent when the Order is fulfilled, then your Fulfill method (or, if more appropriate, the setter for IsFulfilled) should trigger that action. I would probably have configuration information that pointed the business object at an appropriate email service for the application, or more generally to a "notifier" service so that other notification types could be added when/if necessary.

blocks|key|1460772|text|在业务服务中看到很多这样的东西可能看起来很烦人：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1460773|public+Customer+GetCustomer(int+id)
{
+++++return+customerRepository.Get(id);
}|code-block|syntax|javascript|1460774|有一种强烈的冲动想要绕过这项服务，这是很自然的。但从长远来看，允许您的业务服务介于控制器和存储库之间是更好的选择。|1460775|现在，对于一个非常简单的CRUD类型的应用程序，您可以让您的控制器直接使用存储库，而不是通过业务服务。您仍然可以拥有类似于EmailerService的东西，但当涉及到获取和处理实体时，最好不要在控制器中混合和匹配业务服务和存储库调用。|1460776|至于让实体(业务对象)调用服务或任何基础设施组件，我不会这么做。我更喜欢让实体保持POCO和无依赖关系。|1460777|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

It might seem annoying to see lot of this in business services:

<pre><code>public Customer GetCustomer(int id)
{
 return customerRepository.Get(id);
}
</code></pre>

And it's natural to have a strong urge to bypass the service. But you are better off in the long run allowing your business services intermediate between controllers and repositories. 

Now, for a very simple CRUD type application, you could have your controllers consume repositories directly instead of going through business services. You could still have something like an EmailerService, but IMO when it comes to fetching and doing things with entities, best not to mix and match business service and repository calls in your controllers.

As for having entities (business objects) call services or any infrastructure components, I would not do that. I prefer to keep entities POCO and free of dependencies.

blocks|key|1675933|text|如果我们可以停止一遍又一遍地看到这个例子，那将会有所帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1675934|public+ActionResult+Index()
{
++var+widgetContext+=+new+WidgetDataContext();
++var+widgets+=+from+w+in+widgetContext.Widget
++++++++++++++++select+w;
++return+View(widgets);
}|code-block|syntax|javascript|1675935|我确实意识到这对你的问题没有帮助，但它似乎是许多演示软件的一部分，我认为这些演示软件可能会产生误导。|1675936|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

It would help if we could stop seeing this example over and over again ...

<pre><code>public ActionResult Index()
{
 var widgetContext = new WidgetDataContext();
 var widgets = from w in widgetContext.Widget
 select w;
 return View(widgets);
}
</code></pre>

I do realize that this isn't helpful to your question but it seems to be part of a lot of demo-ware that I think can be misleading.

blocks|key|1676102|text|您的控制器(在MVC项目中)应该调用Service项目中的对象。服务项目是处理所有业务逻辑的地方。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1676103|一个很好的例子是：|1676104|public+ActionResult+Index()
{
++++ProductServices+productServices+=+new+ProductServices();

++++//+top+10+products,+for+example.
++++IList<Product>+productList+=+productServices.GetProducts(10);+

++++//+Set+this+data+into+the+custom+viewdata.
++++ViewData.Model+=+new+ProductViewData
+++++++++++++++++++++++++{
+++++++++++++++++++++++++++++ProductList+=+productList;
+++++++++++++++++++++++++};

++++return+View();
}++|code-block|syntax|javascript|1676105|或者使用依赖注入(我最喜欢的)|1676106|//+Field+with+the+reference+to+all+product+services+(aka.+business+logic)
private+readonly+ProductServices+_productServices;

//+'Greedy'+constructor,+which+Dependency+Injection+auto+finds+and+therefore
//+will+use.
public+ProductController(ProductServices+productServices)
{
++++_productServices+=+productServices;
}

public+ActionResult+Index()
{
++++//+top+10+products,+for+example.
++++//+NOTE:+The+services+instance+was+automagically+created+by+the+DI
++++//+++++++so+i+din't+have+to+worry+about+it+NOT+being+instansiated.
++++IList<Product>+productList+=+_productServices.GetProducts(10);+

++++//+Set+this+data+into+the+custom+viewdata.
++++ViewData.Model+=+new+ProductViewData
+++++++++++++++++++++++++{
+++++++++++++++++++++++++++++ProductList+=+productList;
+++++++++++++++++++++++++};

++++return+View();
}|1676107|现在..。什么是服务项目(或者什么是ProductServices)？这是一个包含业务逻辑的类库。例如。|1676108|public+class+ProductServices+:+IProductServices
{
++++private+readonly+ProductRepository+_productRepository;
++++public+ProductServices(ProductRepository+productRepository)
++++{
++++++++_productRepository+=+productRepository;
++++}

++++public+IList<Product>+GetProducts(int+numberOfProducts)
++++{
++++++++//+GetProducts()+and+OrderByMostRecent()+are+custom+linq+helpers...
++++++++return+_productRepository.GetProducts()
++++++++++++.OrderByMostRecent()
++++++++++++.Take(numberOfProducts)
++++++++++++.ToList();
++++}
}|1676109|但这一切可能都是如此的核心和困惑...因此，ServiceProduct类的一个简单版本可以是(但我并不真正推荐)……|1676110|public+class+ProductServices
{
++++public+IList<Product>+GetProducts(int+numberOfProducts)
++++{
++++++++using+(DB+db+=+new+Linq2SqlDb()+)
++++++++{
++++++++++++return+(from+p+in+db.Products
++++++++++++++++++++orderby+p.DateCreated+ascending
++++++++++++++++++++select+p).Take(10).ToList();
++++++++}
++++}
}|1676111|这就对了。您可以看到，所有逻辑都在Service项目中，这意味着您可以在其他地方重用该代码。|1676112|我从哪里学到这个的？|1676113|来自Rob+Conery的MVC+StoreFront媒体和tutorials。自从切片面包以来最好的东西。他的教程用完整的解决方案代码示例很好地解释了(我做了什么)。他使用了依赖注入，现在我已经看到了他在MVC中是如何使用它的。|offset|length|1676114|HTH。|1676115|entityMap|0|LINK|mutability|MUTABLE|url|http://blog.wekeroad.com/|1|http://www.codeplex.com/mvcsamples/Release/ProjectReleases.aspx?ReleaseId=18861|2|http://blog.wekeroad.com/mvc-storefront/^0|0|0|0|0|0|0|0|0|0|0|0|2|A|0|D|E|1|U|9|2|0|0^^$0|@$1|2|3|4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1H|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1I|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|1J|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1K|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|1L|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|1M|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|1N|8|@]|9|@]|A|$]]|$1|S|3|T|5|F|7|1O|8|@]|9|@]|A|$G|H]]|$1|U|3|V|5|6|7|1P|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1R|8|@]|9|@$10|1S|11|1T|1|1U]|$10|1V|11|1W|1|1X]|$10|1Y|11|1Z|1|20]]|A|$]]|$1|12|3|13|5|6|7|21|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|22|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|1B]]|1C|$5|17|18|19|A|$1A|1D]]|1E|$5|17|18|19|A|$1A|1F]]]]

Your controllers (in the MVC project) should be calling your objects in the Service project. The services project is where all the business logic is handled.

A good example is this:

<pre><code>public ActionResult Index()
{
 ProductServices productServices = new ProductServices();

 // top 10 products, for example.
 IList&lt;Product&gt; productList = productServices.GetProducts(10); 

 // Set this data into the custom viewdata.
 ViewData.Model = new ProductViewData
 {
 ProductList = productList;
 };

 return View();
} 
</code></pre>

or with Dependency Injection (my fav)

<pre><code>// Field with the reference to all product services (aka. business logic)
private readonly ProductServices _productServices;

// 'Greedy' constructor, which Dependency Injection auto finds and therefore
// will use.
public ProductController(ProductServices productServices)
{
 _productServices = productServices;
}

public ActionResult Index()
{
 // top 10 products, for example.
 // NOTE: The services instance was automagically created by the DI
 // so i din't have to worry about it NOT being instansiated.
 IList&lt;Product&gt; productList = _productServices.GetProducts(10); 

 // Set this data into the custom viewdata.
 ViewData.Model = new ProductViewData
 {
 ProductList = productList;
 };

 return View();
}
</code></pre>

Now .. what's the Service project (or what is ProductServices)? that's a class library with your business logic. For example.

<pre><code>public class ProductServices : IProductServices
{
 private readonly ProductRepository _productRepository;
 public ProductServices(ProductRepository productRepository)
 {
 _productRepository = productRepository;
 }

 public IList&lt;Product&gt; GetProducts(int numberOfProducts)
 {
 // GetProducts() and OrderByMostRecent() are custom linq helpers...
 return _productRepository.GetProducts()
 .OrderByMostRecent()
 .Take(numberOfProducts)
 .ToList();
 }
}
</code></pre>

but that might be all so hardcore and confusing... so a simple version of the ServiceProduct class could be (but i wouldn't really recommend) ...

<pre><code>public class ProductServices
{
 public IList&lt;Product&gt; GetProducts(int numberOfProducts)
 {
 using (DB db = new Linq2SqlDb() )
 {
 return (from p in db.Products
 orderby p.DateCreated ascending
 select p).Take(10).ToList();
 }
 }
}
</code></pre>

So there you go. You can see that all the logic is in the Service projects, which means u can reuse that code in other places.

Where did i learn this?

From <a href="http://blog.wekeroad.com/" rel="nofollow noreferrer" title="Rob Conery&#39;s main blog">Rob Conery</a>'s <a href="http://www.codeplex.com/mvcsamples/Release/ProjectReleases.aspx?ReleaseId=18861" rel="nofollow noreferrer" title="Code is found here">MVC StoreFront</a> media and <a href="http://blog.wekeroad.com/mvc-storefront/" rel="nofollow noreferrer" title="Rob&#39;s blog, but filtered by MVC Storefront posts and tutorials">tutorials</a>. Best thing since sliced bread.
His tutorials explain (what i did) in good detail with full solution code examples. He uses Dependency Injection which is SOO kewl now that i've seen how he uses it, in MVC.

HTH.

blocks|key|1676221|text|我不确定是否要使用服务来实现这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1676222|据我所知，DDD的原则之一(我现在正在阅读)是将域对象组织到Aggregate中，并且当您创建Aggregate根的实例时，它只能直接处理Aggregate中的对象(以帮助维护清晰的责任感)。|1676223|创建聚合应该强制执行任何不变式等。|1676224|以Customer类为例，Customer可能是聚合根，聚合中的另一个类可能是Address。|1676225|现在，如果您想创建一个新客户，您应该能够使用Customer构造函数或工厂来完成此操作。这样做应该返回一个在聚合边界内具有完整功能的对象(因此它不能处理产品，因为这些产品不是聚合的一部分，但它可以处理地址)。|1676226|数据库是次要关注点，仅在将聚合持久存储到数据库或从数据库中检索它时才起作用。|1676227|为了避免直接与数据库交互，您可以创建一个Repository接口(如上所述)，在给定Customer实例(其中包括对Address的引用)的情况下，该接口应该能够将聚合持久存储到数据库。|1676228|重点是Repository接口是域模型/层的一部分(+Repository的实现不是)。另一个因素是，存储库可能最终应该调用相同的"create“方法，就像您正在创建一个新对象一样(以维护不变量等)。如果你使用的是一个构造函数，这就足够简单了，因为当存储库从数据“创建”对象时，你最终会调用构造函数。|1676229|应用层可以直接与域通信(包括存储库接口)。|1676230|因此，如果你想创建一个对象的新实例，你可以例如|1676231|Customer+customer+=+new+Customer();|code-block|syntax|javascript|1676232|如果应用程序需要从存储库中检索customer的实例，我想不出什么特别的理由让它不调用...|1676233|Customer+customer+=+_custRepository.GetById(1)|1676234|或者..。|1676235|Customer+customer+=+_custRepository.GetByKey("AlanSmith1")|1676236|最终，它将以Customer对象的一个实例结束，该实例在它自己的限制和规则内运行，就像它直接创建新的Customer对象一样。|1676237|我认为当你试图使用的“东西”不是一个对象时，应该保留服务。大多数规则(约束等)都可以作为域对象本身的一部分来编写。|1676238|一个很好的例子就是我目前正在阅读的DDD快速pdf。在其中，它们对书架对象有一个约束，借此，您只能添加书架所能容纳的书。|1676239|在BookShelf对象上调用AddBook方法可以在将图书添加到书架的图书对象集合之前检查是否有可用的空间。这是一个简单的示例，但是业务规则是由域对象本身强制执行的。|1676240|顺便说一句，我并不是说上面的任何一个都是正确的！我现在正试着把这一切都弄清楚！|1676241|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1J|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1K|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1L|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1M|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1N|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1O|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1P|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1R|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|1S|8|@]|9|@]|A|$W|X]]|$1|Y|3|Z|5|6|7|1T|8|@]|9|@]|A|$]]|$1|10|3|11|5|V|7|1U|8|@]|9|@]|A|$W|X]]|$1|12|3|13|5|6|7|1V|8|@]|9|@]|A|$]]|$1|14|3|15|5|V|7|1W|8|@]|9|@]|A|$W|X]]|$1|16|3|17|5|6|7|1X|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|20|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|21|8|@]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|22|8|@]|9|@]|A|$]]]|1H|$]]

I'm not sure about using services for this.

As I understand it, one of the principles of DDD (which I'm reading up on at the moment) is that the Domain Objects are organised into Aggregates and that when you create an instance of the Aggregate root, it can only directly deal with the objects within the Aggregate (to help maintain a clear sense of responsibility).

Creating the Aggregate should enforce any invariants etc.

Taking an example of a Customer class, the Customer might be the Aggregate root and another class within the Aggregate might be Address.

Now if you want to create a new Customer, you should be able to do this using either the Customer constructor or a factory. Doing this should return an object which is fully functional within the Aggregate boundary (so it can't deal with Products as these are not part of the Aggregate but it can handle Addresses).

The database is a secondary concern and only comes into play for persisting the Aggregate to the database, or retrieving it from the database.

To avoid interfacing with the database directly you can create a Repository interface (as discussed) which given an instance of Customer (which includes a reference to Address) should be able to persist the Aggregate to the database.

The point is that the Repository interface IS part of your domain model/layer (the Implementation of the Repository is not). The other factor is that the repository probably should end up calling the same "create" method as if you were creating a new object (to maintain invariants etc). If you're using a constructor this is simple enough as you will end up calling the constructor when the repository "creates" the object from data anyway.

The application layer can directly communicate with the domain (including the repository interface).

So if you want to create a new instance of an object you can e.g.

<pre><code>Customer customer = new Customer();
</code></pre>

If the app needs to retrieve an instance of the customer from the repository, there's no particular reason I can think of for it not to call...

<pre><code>Customer customer = _custRepository.GetById(1)
</code></pre>

or...

<pre><code>Customer customer = _custRepository.GetByKey("AlanSmith1")
</code></pre>

Ultimately it will end up with an instance of the Customer object which functions within it's own limits and rules just as it would if it created the new Customer object directly.

I think services should be reserved for when the "thing" you are trying to work with just isn't an object. Most rules (constraints etc) can be written as part of the Domain Object itself.

A good example is in the DDD Quickly pdf I'm reading at the moment. In there they have a constraint on a Bookshelf object, whereby you can only add as many books as the shelf can contain.

Calling the AddBook method on the BookShelf object checks that space is available before adding the book to the BookShelf's collection of Book objects. A simple example but the business rule is enforced by the Domain Object itself.

I'm not saying any of the above is correct by the way! I'm trying to get my head around all this at the moment!

The controllers in my ASP.NET MVC web app are starting to get a bit bloated with business logic. The examples on the web all show simple controller actions that simply pull data out of a repository and pass it to the view. But what if you also need to support business logic on top of that? 

Say, for instance, an action that fulfills an order also needs to send an e-mail out. Do I stick this in the controller and copy/paste this logic to any other actions that also fulfill orders? My first intuition would be to create a service like OrderFulfillerService that would take care of all this logic and have the controller action call that. However, for simple operations like retrieving a list of users or orders from the database, I would like to interact directly with the repository instead of having that call wrapped by a service.

Is this an acceptable design pattern? Controller actions call services when they need business logic and repositories when they just need data access?

Should controllers in an ASP.NET MVC web app call repositories, services, or both?

数据库

我的ASP.NET MVC应用中的控制器开始因为业务逻辑而变得有点臃肿。web上的示例都显示了简单的控制器操作，这些操作只是将数据从存储库中拉出并将其传递给视图。但是，如果您还需要在此基础上支持业务逻辑呢？例如，执行订单的操作还需要发送一封电子邮件。我是否将其粘贴到控制器中，并将此逻辑复制/粘贴到也满足订单的任何其他操...

问ASP.NET MVC web应用程序中的控制器应该调用存储库、服务，还是两者都调用？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ASP.NET MVC web应用程序中的控制器应该调用存储库、服务，还是两者都调用？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ASP.NET MVC web应用程序中的控制器应该调用存储库、服务，还是两者都调用？
EN