方法放在哪里。存储库上的服务层（ BL ）？

Question

我对一件事感到困惑。我在以前的 mvc 应用程序中使用了存储库模式（不是通用的），并且我曾经在其中包含某种业务逻辑。此刻我读到了应该包含 BL 的服务层模式。但是现在不知道是否有更多的抽象和额外的代码，而不是清晰/可读和高效的代码。

我想实现这样的方法

public void ChangeActiveField(bool isActive, int id)
{
  var objectToUpdate = _context.FirstOrDefault(x=>x.id==id);
  objectToUpdate.IsActive - isActive;
  _context.Entry(objectToUpdate).State = System.Data.Entity.EntityState.Modified;
  _context.Save();
}

在这段代码中有一些业务逻辑，我在其中更改一个字段的状态，然后更新它。 我应该在服务层制作它，然后使用简单的存储库更新方法，例如：？

public class MyService
{
  private readonly IMyRepository = _myRepo;

  MyService(IMyRepository myRepo) //it's injectable
  {
    _myRepo = myRepo;
  }

  public void ChangeActiveField(bool isActive, int id) 
  {
     var myObject = _myRepo.GetMyObject(id);
     myObject.IsActive = isActive;
    _myRepo.Update(myObject);
  }

}

这是更好的方法吗？分离效果更好吗？或者它太复杂和覆盖？ 感谢您的帮助。 最好的问候。

Answer 1

一般存储库应该仅封装访问数据库的逻辑（上下文初始化、事务、连接等）。创建通用 CRUD 存储库并将其重用于所有业务实体是很常见的。 所有与业务相关的逻辑都应该放在业务层（服务层）中。 这种方法的主要好处是：

1. 可测试性 - 您可以通过注入虚假存储库（存根）来测试业务逻辑，而无需依赖具体的存储库实现。
2. 解耦 - 您的业务层和 UI 都没有与特定数据库耦合，如果明天您决定将数据库从 SQL 服务器迁移到 Redis（NoSQL 数据库），您的更改将仅包含在存储库层中。
3. 可维护性 - 每一层都有明确的关注点分离：UI - 与用户的交互，BL - 业务逻辑的实现，存储库 - 与 DB 的交互。

根据我的经验，拥有一个业务层（无论一开始多么简单 - 它通常与您的项目一起发展）总是一个好主意。

顺便说一句，如果您使用 EF，一些开发人员将存储库视为不必要的抽象层（在某种程度上，EF 数据库上下文是存储库...）。

我学到的一件事是，主要的工作不是项目的开发阶段，而是维护和升级 - 这里有一个业务层会产生重大影响。

免责声明：这是我根据我的经验得出的主观意见