2013-02-15 78 views
58

根据我的理解,MVC通过作为控制器的“胶水”将演示文稿(视图)中的类定义(模型)分开。控制者应该有一个单一的责任,因此是可以测试的。 ViewModels用于将来自多个实体的数据汇总在一起,并从控制器为视图“按摩”数据。为我的MVC应用程序创建一个服务层?

看起来业务逻辑似乎并没有真正的地方......所以我认为另一层服务是适合的。我只是不确定在哪里放置这个图层,或者如何构建这些服务 - 它应该是一个名为“services”的类,它包含一系列函数?我对MVC有点新,所以任何阅读材料,样本或一般新人类型的提示都会很棒。

回答

97

我通常在开发ASP.NET MVC应用程序时使用服务层。它类似于马丁福勒在中讨论的Service Layer Pattern企业应用架构模式。它封装了您的业务逻辑并使控制器变得非常简单。基本上,控制器使用服务层获取域模型,然后将其转换为视图模型。我还使用Unit of Work Design Pattern来处理事务,使用Repository Design Pattern来封装数据访问层,以便更容易地进行单元测试,并且能够轻松更换ORM。该图显示了我在MVC应用程序中使用的典型图层。

MVC Architecture

服务层标记为这个图,因为我觉得人眼花缭乱,当你使用“服务层”中的“应用程序或领域层”。他们倾向于认为这是一项网络服务。它实际上是一个可用于您最喜爱的Web服务技术(如ASP.NET Web API或WCF)以及控制器的程序集。

至于命名约定,我通常使用描述服务域后面的内容。例如,如果我有一个处理用户成员资格的服务层,那么我将拥有一个名为MembershipService的类,该类具有控制器和/或Web服务所需的所有方法来查询和操作成员资格域。请注意,您可能在同一个应用程序中有多个域,因此您可以拥有多个服务层。我的意思是在这里,你不必有一个单一的服务,照顾整个应用程序。

+0

谢谢凯文。 >>> – user2062383 2013-02-15 21:56:20

+4

那里有一个很好的例子来实现这种方法吗? – Animesh 2013-10-17 13:57:10

+0

@Animesh你只需要在网络中编写例子,EF + Code First或POCO模板用于DAL,T4Scaffolding用于生成Repository和UnitOfWork,Service只是在DAL和POCO封装业务逻辑之间进行协调。然后ASP.NET MVC控制器或WebApi只调用服务层并显示结果(ASP.NET MVC)或将其暴露给其他客户端(ASP.NET WebApi) – 2013-12-02 13:37:02

7

看看的article从MSDN的最佳实践。

文章中的应用程序的源代码可以找到here

21

我的建议是创建一个单独的类,称为“服务”。将它们放在不同的类库(或名称空间)项目中,并使它们在MVC框架基础结构上独立。我建议也使用某种依赖注入(最好的是构造函数注入)。然后你的服务类可能看起来像:

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

    public MyService(IFirstDependency firstService, ISecondDependency secondService) 
    { 
    } 

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

然后,你从你的控制器使用这些服务。 查看完整示例here

根据存储库 - 如果你打算使用一些现代ORM(NHibernate,EntityFramework),我的建议是不使用它们,因为你的业务逻辑将被封装在服务层中,并且你的数据库已经被封装在ORM框架。

+1

我认为跳过存储库部分并直接转到ORM的问题在于,您的服务类将直接获取ORM上下文,这意味着您的服务中的所有这些类都可以访问您拉入上下文的所有表,而不是每个服务类只处理它需要的表。你可以通过将DbSet传入每个课程的Ctor并用DI解决这个问题来避免这种情况,但是你可能会遇到问题? – user441521 2016-08-12 18:23:00

6

“Business logic should be in a service, not in a model”?报价:

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

有些人错误地认为采取100线控制器方法,并将其全部推向服务以某种方式使得更好的体系结构。它确实没有;它所做的只是添加另一个可能不必要的间接层。实际上,控制器仍然在做这项工作,它只是通过一个名字很差的“帮手”对象来实现。我强烈推荐Jimmy Bogard的Wicked Domain Models演示文稿,了解如何将贫血域模型转化为有用的模型。它涉及仔细检查您公开的模型以及哪些操作在业务环境中实际有效。

相关问题