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存储库并将其重用于所有业务实体是很常见的。所有与业务相关的逻辑都应放在业务层（服务层）中。这种方法的主要好处是：

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

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

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

我已经了解到的一点是，主要工作不是项目的开发阶段，而是维护和升级 - 这里的业务层面临着重大影响。

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

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

1 个答案: