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

25 浏览
0 Comments

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

假设我有以下存储库模式：

interface IGenericRepo where T : class
{
     IEnumerable GetAll();
     T GetById(object id);
     void Insert(T obj);
     void Update(T obj);
     void Delete(T obj);
     void Save();
}
interface ICustRepo : IGenericRepo
{
     IEnumerable GetBadCust();
     IEnumerable GetGoodCust();
}
public class CustRepo : ICustRepo
{
     //在这里实现方法
}

然后在我的控制器中：

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); 
     }
}

基本上，我的模式是这样的：

视图<->控制器->存储库->EF->SQL Server

但我看到很多人这样做：

视图<->控制器->服务->存储库->EF->SQL Server

所以我的问题是：

1. 为什么以及何时需要服务层？这不是只是增加了另一个不必要的层吗，因为每个非泛型方法已经在ICustRepo中实现了吗？

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

3. 服务层应该与我的存储库一一对应吗？

我已经搜索了几天，但对答案不满意。

任何帮助将不胜感激，对糟糕的英语表示歉意。

谢谢。

更新：我已经阅读了存储库和服务层之间的区别？。我已经知道这两者的区别，但我想知道为什么和目的。因此，那并没有回答我的问题。

0

2 答案

0 Comments

MVC设计模式是一种常用的软件架构模式，它将应用程序分为三个主要部分：模型（Model）、视图（View）和控制器（Controller）。其中，服务层（Service Layer）是负责整个业务逻辑的地方。

在一个典型的MVC架构中，控制器负责准备视图模型（ViewModel）并将其传递给特定的视图；仓库（Repository）则是负责从数据库中获取实体的抽象层；而服务层则是负责处理复杂逻辑的地方。通常情况下，服务层会使用多个实体来进行某些逻辑操作，并返回数据传输对象（DTO）。

在我的观点中，服务层应该返回DTO对象，并在控制器中将其映射为视图模型。

然而，有人提出了一个问题，即是否可以将所有方法都从仓库移到服务层。这样做的话，仓库只会包含基本的操作（如插入、更新、删除、获取全部等），而更复杂的方法则移到服务层。对此，有人认为这样做是合理的，因为服务层可以处理更多的业务逻辑，而仓库只需要保留基本操作。

然而，也有人对此提出了疑问。他认为，如果将所有方法都移到服务层，那么当服务层需要调用仓库的某个方法时（如获取所有客户），系统会将所有的实体都传递给服务层，然后在服务层中进行过滤和处理，最后返回符合要求的实体。这样一来，服务层的性能就会受到影响，特别是在处理更复杂的查询和更多记录的情况下。

针对这个问题，有人认为直接在仓库中定义这些方法可能更好。因为在企业应用程序中，可能需要使用多个内连接、联合查询等复杂操作来获取所需的值。将这些方法放在仓库中可以更好地利用数据库的性能，避免不必要的数据传输和处理过程。

服务层在MVC架构中扮演着重要的角色，负责处理复杂的业务逻辑。在设计中，需要权衡考虑将哪些方法放在服务层，哪些方法放在仓库中，以便充分利用数据库的性能，并保持系统的高效性。

0
0 Comments

MVC设计模式，服务层目的的出现原因及解决方法

在典型的三层架构中，包括展示层（Presentation Layer），服务/领域层（Service/Domain Layer）和数据访问层（Data Access Layer，简称DAL）。

将服务层视为应用程序的“核心”。通常，服务层只有存储库接口，这些接口将在数据访问层中实现。因此，它允许您“轻松”切换访问数据的方式。服务层返回的对象不应该是数据访问对象（DAO），因为毕竟，展示层甚至不“知道”数据访问层的存在。

现在假设有一个三层解决方案。目前，所有层都没有太多意义。

/-------------------\

| Web App | <-- 展示层

|-------------------|

| Service Library | <-- 服务层

|-------------------|

| Entity Framework | <-- 数据访问层

\-------------------/

现在，想要在ASP.NET MVC WebApi中添加一个REST API。

/--------------------\

| Web App | REST API | <-- 展示层

|--------------------|

| Service Library | <-- 服务层

|--------------------|

| Entity Framework | <-- 数据访问层

\--------------------/

现在，例如，不再希望使用Entity Framework作为数据访问，而是想要使用NHibernate。

/--------------------\

| Web App | REST API | <-- 展示层

|--------------------|

| Service Library | <-- 服务层

|--------------------|

| NHibernate | <-- 数据访问层

\--------------------/

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

通常，服务层公开接口供数据访问层实现，以便我们获得所需的“抽象”。我在大学中实施了一个使用这种架构的项目。您可以在这里查看代码。

希望这对您有所帮助。如果我解释事情很乏味，对不起：P

“注意，我们添加了一种新的展示形式，并切换了访问数据的方式，但是服务层从未改变过。”这就是我所需要的。谢谢！

您能详细解释一下为什么服务层使用接口向客户端公开自身吗？接口似乎通常与实际的服务类成一对一的关系，为什么要使用接口？

接口是为数据访问层准备的。例如，您有一个名为PersonRepository的接口，由数据访问层实现，例如：PersonRepositoryNHibernateRepositoryImpl，您可以配置依赖注入容器，以注入新模块/项目中的类。

0