asp.net-mvc 为我的 MVC 应用程序创建服务层？

Creating a Service Layer for my MVC application?

提问by user2062383

From what I understand, MVC separates the class definitions (model) from the presentation (view) via the "glue" that is the controller. The controller should have a single responsibility and therefore be testable. ViewModels are used to bring together data from multiple entities and to "massage" the data from the controller for the view.

据我了解，MVC 通过作为控制器的“胶水”将类定义（模型）与表示（视图）分开。控制器应该有一个单一的责任，因此是可测试的。ViewModel 用于将来自多个实体的数据汇集在一起​​，并为视图“按摩”来自控制器的数据。

It seems like business logic doesn't really have a place... so I'm thinking another layer for services would be suitable. I'm just not sure where to place this layer, or how to build the services - should it be a class called "services" that contains a bunch of functions? I'm a bit new to MVC, so any reading material, samples, or general newcomer kind of tips would be awesome.

似乎业务逻辑并没有真正占据一席之地……所以我认为服务的另一层是合适的。我只是不确定将这一层放在哪里，或者如何构建服务——它应该是一个包含一堆功能的名为“服务”的类吗？我对 MVC 有点陌生，所以任何阅读材料、示例或一般的新手技巧都会很棒。

回答by Kevin Junghans

I usually use a Service Layer when developing ASP.NET MVC application. It is similar to the Service Layer Patternthat Martin Fowler discusses in Patterns of Enterprise Application Architecture. It encapsulates your business logic and make the controllers pretty thin. Basically the controllers use the service layer to get the domain models that are then transformed into view models. I also use the Unit of Work Design Patternto handle transactions and the Repository Design Patternto encapsulate the data access layer for easier unit testing and being able to easily swap out ORM's. This figure shows the typical layers that I use in an MVC application.

我通常在开发 ASP.NET MVC 应用程序时使用服务层。它类似于Martin Fowler 在Patterns of Enterprise Application Architecture 中讨论的服务层模式。它封装了您的业务逻辑并使控制器非常精简。基本上，控制器使用服务层来获取域模型，然后将其转换为视图模型。我还使用工作单元设计模式来处理事务，使用存储库设计模式来封装数据访问层，以便于进行单元测试并能够轻松更换 ORM。此图显示了我在 MVC 应用程序中使用的典型层。

The service layer is labeled as the "Application or Domain Layer" in this diagram because I find people get confused when you use the term "Service Layer". They tend to think that this is a web service. It is actually an assembly which can be used by your favorite web service technology, such as ASP.NET Web API or WCF, as well as a controller.

在此图中，服务层被标记为“应用程序或领域层”，因为我发现当您使用术语“服务层”时人们会感到困惑。他们倾向于认为这是一个网络服务。它实际上是一个可以由您最喜欢的 Web 服务技术（例如 ASP.NET Web API 或 WCF）以及控制器使用的程序集。

As for naming conventions I usually use something that describes the domain followed by service. For example, If I have a service layer that handles user membership then I would have a class called MembershipService that has all of the methods needed by controllers and and web services to query and manipulate the membership domain. Note you may have several domains in the same application so you can have multiple service layers. My point being here that you do not have to have one monolithic service that takes care of the whole application.

至于命名约定，我通常使用描述域后跟服务的东西。例如，如果我有一个处理用户成员资格的服务层，那么我将拥有一个名为 MembershipService 的类，它具有控制器和 Web 服务所需的所有方法来查询和操作成员资格域。请注意，您可能在同一个应用程序中有多个域，因此您可以拥有多个服务层。我的观点是，您不必拥有一个单一的服务来处理整个应用程序。

回答by Marian Ban

My advice is to create a separate classes called "services". Put them in different class library (or namespace) project and make them independent on MVC framework infrastructure. I recommend to use also some kind of dependency injection (the best is constructor injection). Then your service classes may look like:

我的建议是创建一个单独的类，称为“服务”。将它们放在不同的类库（或命名空间）项目中，并使它们独立于 MVC 框架基础架构。我建议也使用某种依赖注入（最好的是构造函数注入）。那么您的服务类可能如下所示：

 public class MyService : IMyService
 {
     IFirstDependency _firstService;
     ISecondDependency _secondService;

     public MyService(IFirstDependency firstService, ISecondDependency secondService)
     {
     }

     public Result DoStuf(InputDTO)
     {
         // some important logic         
     }
 }

Then you consume these service from your controllers. Look herefor complete example.

然后您从控制器使用这些服务。看看这里为完整的例子。

According Repositories - my advice is to do not use them if you are going to use some modern ORM (NHibernate, EntityFramework), because your business logic will be encapsulated in the Service Layer and your database will be already encapsulated with the ORM framework.

根据 Repositories - 我的建议是，如果您打算使用一些现代 ORM（NHibernate、EntityFramework），请不要使用它们，因为您的业务逻辑将被封装在服务层中，而您的数据库将已经被 ORM 框架封装。

回答by emre nevayeshirazi

Take a look at the articlefrom MSDN best practices.

查看来自 MSDN 最佳实践的文章。

Source code of the application in article can be found here.

可以在此处找到文章中应用程序的源代码。

回答by Arvand

Quoting from “Business logic should be in a service, not in a model”?:

引用“业务逻辑应该在服务中，而不是在模型中”？：

In an MVP/MVC/MVVM/MV* architecture, services don't exist at all. Or if they do, the term is used to refer to any generic object that can be injected into a controller or view model. The business logic is in your model. If you want to create "service objects" to orchestrate complicated operations, that's seen as an implementation detail. A lot of people, sadly, implement MVC like this, but it's considered an anti-pattern (Anemic Domain Model) because the model itself does nothing, it's just a bunch of properties for the UI.

在 MVP/MVC/MVVM/MV* 架构中，服务根本不存在。或者，如果他们这样做，该术语用于指代任何可以注入控制器或视图模型的通用对象。业务逻辑在您的模型中。如果你想创建“服务对象”来编排复杂的操作，这被视为一个实现细节。遗憾的是，很多人都这样实现 MVC，但它被认为是一种反模式（贫血域模型），因为模型本身什么都不做，它只是 UI 的一堆属性。

Some people mistakenly think that taking a 100-line controller method and shoving it all into a service somehow makes for a better architecture. It really doesn't; all it does is add another, probably unnecessary layer of indirection. Practically speaking, the controller is still doing the work, it's just doing so through a poorly named "helper" object. I highly recommend Jimmy Bogard's Wicked Domain Modelspresentation for a clear example of how to turn an anemic domain model into a useful one. It involves careful examination of the models you're exposing and which operations are actually valid in a business context.

有些人错误地认为，采用 100 行的控制器方法并将其全部推入服务中会以某种方式获得更好的架构。真的没有；它所做的只是添加另一个可能不必要的间接层。实际上，控制器仍然在做这项工作，它只是通过一个名字很差的“助手”对象来完成的。我强烈推荐 Jimmy Bogard 的Wicked Domain Models演示文稿，它是一个清晰的示例，说明如何将一个贫乏的领域模型转变为有用的领域模型。它涉及仔细检查您公开的模型以及哪些操作在业务环境中实际有效。

回答by mnsr

Sounds like you'd be after something like a repository pattern. You can read about it here:

听起来你会追求像存储库模式这样的东西。你可以在这里读到它：

http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net- mvc-应用程序

This answer here may also help:

这里的答案也可能有帮助：

Best Repository Pattern for ASP.NET MVC

ASP.NET MVC 的最佳存储库模式