c# - 把方法放在哪里。存储库上的服务层 ( 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. 可测试性 - 您可以通过注入(inject)虚假存储库( stub )来测试您的业务逻辑，而无需依赖具体的存储库实现。
2. 解耦——你的业务层和你的用户界面都没有耦合到特定的数据库，如果明天你决定将你的数据库从 SQL 服务器迁移到 Redis(NoSQL 数据库)，你的更改将只包含在存储库层。
3. 可维护性 - 每个层的关注点都有明确的分离:UI - 与用户的交互，BL - 业务逻辑的实现，存储库 - 与 DB 的交互。

根据我的经验，拥有一个业务层(无论它在开始时多么简单 - 它通常与您的项目一起成长)总是一个好主意。

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

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

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