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

所以我的问题是：

为什么以及什么时候需要 service layer？这不就是再增加一个不必要的层吗，因为每个非泛型方法都已经在 ICustRepo?
服务层应该returnDTO还是我的ViewModel？
服务层应该 1:1 与我的存储库映射吗？

我看了几天，但我对答案并不满意。

如有任何帮助，我们将不胜感激，对于糟糕的英语，我们深表歉意。

谢谢。

更新：

Difference between Repository and Service Layer?

我已经读过了。我已经知道这两者之间的区别，但我想知道原因和目的。所以这不能回答我的问题

Answer 1

Ad.1 服务层应该放置整个业务逻辑。更多的是关于不同的职责：

Controller - 负责准备viewModel并传递给具体的视图，
存储库 - 负责从数据库收集实体的抽象层
服务 - 负责复杂的逻辑。通常情况下，服务使用许多实体来制作一些逻辑，而 return 只是 DTO。

Ad.2 在我看来服务层应该 return DTO 对象应该映射到控制器中的 viewModels。

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

Answer 2

TL;DR

见下文解释
服务层之上的层不应“意识到”服务层之下存在更多层。
不一定，因为例如您可以将 1 种类型的数据分散在 2 个表中，而“核心”只看到一个，数据访问层负责“分组”并返回服务层类型

说明

典型的 3 层架构由表示层、Service/Domain 层、数据访问层 (DAL) 组成。

将服务层视为应用程序的“核心”。通常，服务层只有将在 DAL 中实现的存储库接口。

因此，它可以让您“轻松”切换访问数据的方式。服务层返回的对象应该不是DAO的，因为毕竟Presentation Layer甚至“不知道”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
      \--------------------/

请注意，我们添加了一种新的表示形式并切换了我们访问数据的方式，但服务层从未改变。

通常，服务层公开要在数据访问层中实现的接口，以便我们获得所需的“抽象”。

我在大学里用这个架构实现了一个项目。你可以查看代码HERE

希望对您有所帮助。对不起，如果我这么无聊@解释事情：P

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

MVC design pattern, service layer purpose?

c#

asp.net-mvc

design-patterns

entity-framework

repository