MVC设计模式,服务层目的？

Question

假设我有以下回购模式:

interface IGenericRepo<T> where T : class
{
     IEnumerable<T> GetAll();
     T GetById(object id);
     void Insert(T obj);
     void Update(T obj);
     void Delete(T obj);
     void Save();
}

interface ICustRepo : IGenericRepo<Cust>
{
     IEnumerable<Cust> GetBadCust();
     IEnumerable<Cust> GetGoodCust();
}

public class CustRepo : ICustRepo<Cust>
{
     //implement method here
}

然后在我的控制器中:

public class CustController
{
     private ICustRepo _custRepo;

     public CustController(ICustRepo custRepo)
     {
         _custRepo = custRepo;
     }

     public ActionResult Index()
     {
         var model = _custRepo.GetAll();
         return View(model);
     }

     public ActionResult BadCust()
     {
         var model = _custRepo.GetBadCust();
         return View(model); 
     }
}

基本上我的模式是这样的

View <-> Controller -> Repo -> EF -> SQL Server

但我看到很多人这样做

View <-> Controller -> Service -> Repo -> EF -> SQL Server

所以我的问题是:

1. 为什么以及何时需要service layer？这不仅仅是添加另一个不必要的层,因为每个非泛型方法已经实现了ICustRepo吗？

2. 服务层应该返回DTO还是我的ViewModel？

3. 服务层应该与我的仓库1:1映射吗？

我环顾了几天,但我对答案并不满意.

任何帮助将不胜感激并为糟糕的英语道歉.

谢谢.

更新:

存储库和服务层之间的区别？

我已经读过了.我已经知道那些2之间的区别,但我想知道为什么和目的.所以这不回答我的问题

Answer 1

TL; DR

1. 见下面的解释
2. 服务层之上的层不应"意识到"服务层下面存在更多层.
3. 不一定,因为您可以拥有分散在2个表中的1个类型的数据,而"核心"只看到1个,数据访问层负责"分组"并返回服务层类型

说明

典型的3层体系结构由表示层,服务/域层,数据访问层(DAL)组成.

将服务层视为应用程序的"核心".Tipical Service Layer仅具有将在DAL中实现的存储库接口.

因此,它允许您"轻松"切换访问数据的方式.服务层返回的对象不应该是DAO,因为毕竟,表示层甚至不"知道"DAL存在.

场景:您有一个3层解决方案.目前在拥有所有图层方面没有多大意义.

      /-------------------\
      |      Web App      | <--- Presentation Layer
      |-------------------|
      |  Service Library  | <--- Service Layer
      |-------------------|
      | Entity Framework  | <--- Data Access
      \-------------------/

现在,您希望在ASP.NET MVC WebApi中拥有REST API

      /--------------------\
      | Web App | REST API | <--- Presentation Layer
      |--------------------|
      |  Service Library   | <--- Service Layer
      |--------------------|
      |  Entity Framework  | <--- Data Access
      \--------------------/

现在,例如,您不再希望将Entity Framework用作数据访问并希望使用NHibernate.

      /--------------------\
      | Web App | REST API | <--- Presentation Layer
      |--------------------|
      |  Service Library   | <--- Service Layer
      |--------------------|
      |     NHibernate     | <--- Data Access
      \--------------------/

请注意,我们添加了一种新形式的Presentation并切换了访问Data的方式,但Service Layer从未更改过.

专门的服务层公开了要在数据访问层中实现的接口,因此我们得到了我们想要的"抽象".

我在大学实施了这个架构的项目.你可以在这里查看代码

我希望这有帮助.对不起,如果我很无聊@解释事情:P

Answer 2

Ad.1 服务层应该是整个业务逻辑的地方。更多的是关于单独的职责：

• 控制器 - 负责准备 viewModel 并传递给特定的视图，

• Repository - 负责从 DB 收集实体的抽象层

• 服务——负责复杂的逻辑。通常情况下，服务使用许多实体来制作一些逻辑并仅返回 DTO。

Ad.2 在我看来，服务层应该返回 DTO 对象，这些对象应该映射到控制器中的视图模型。

Ad.3 不，情况并非如此。在您的示例中，您可以将 GetBadCust 和 GetGoodCust 从 repo 移动到服务并返回一些 DTO