使用实体框架时，存储库应该是工作单元的属性吗？

Question

我在网上搜索，寻找使用实体框架的存储库/工作单元模式的良好实现。我遇到的所有事情要么在抽象的某个点紧密耦合，要么假设工作单元和存储库使用的DbContext 是共享的，并且应该为整个HTTP 请求而存在（每个请求的实例通过依赖注入)。

例如，假设您正在使用服务层的存储库，服务构造函数可能如下所示：

public DirectoryService(IUnitOfWork unitOfWork, ICountryRepository countryRepo, IProvinceRepository provinceRepo)
{
    /* set member variables... */
}

工作单元构造函数可能如下所示：

public UnitOfWork(IDbContext context)
{
    _context = context;
}

存储库构造函数可能如下所示：

CountryRepository(IDbContext context)
{
    _context = context;
}

此解决方案盲目假设依赖注入正在设置工作单元和存储库以使用每个请求的实例共享相同的 IDbContext。这真的是一个安全的假设吗？

如果您对每个请求的实例使用依赖注入，则相同的 IDbContext 将被注入到多个工作单元中。工作单元不再是原子的，是吗？我可能在一个服务中有待处理的更改，然后在另一个服务中提交，因为上下文在多个工作单元之间共享。

对我来说，设置IDbContextFactory 并为每个工作单元获取新的数据库上下文似乎更有意义。

public interface IDbContextFactory
{
    IDbContext OpenContext();
}

public class UnitOfWork 
{
    private IDbContextFactory _factory;
    private IDbContext _context;

    UnitOfWork(IDbContextFactory factory)
    {
        _factory = factory;
    }

    internal IDbContext Context
    {
        get { return _context ?? (_context = _factory.OpenContext()); }
    }
}

然后问题就变成了，我如何使我的工作单元实现可用于注入的存储库？我不想为每个请求假设实例，因为那样我就回到了我开始的同一条船上。

我唯一能想到的就是效仿 Entity Framework 并将存储库 (IDbSet<T>) 成为工作单元 (DbContext) 的一部分。

那么我的工作单元可能如下所示：

public class DirectoryUnitOfWork : IDirectoryUnitOfWork
{
    private IDbContextFactory _factory;
    private IDbContext _context;

    public DirectoryUnitOfWork(IDbContextFactory factory)
    {
        _factory = factory;
    }

    protected IDbContext Context 
    {
        get { return _context ?? (_context = _factory.OpenContext()); }
    }

    public ICountryRepository CountryRepository
    {
        get { return _countryRepo ?? (_countryRepo = new CountryRepository(Context)); }
    }

    public IProvinceRepository ProvinceRepository
    {
        get { return _provinceRepo ?? (_provinceRepo = new ProvinceRepository(Context)); }
    }

    void Commit()
    {
        Context.SaveChanges();
    }
}

然后我的目录服务开始看起来像这样

public class DirectoryService : IDirectoryService
{
    private IDirectoryUnitOfWork _unitOfWork;

    public DirectoryService(IDirectoryUnitOfWork unitOfWork)
    {
        _unitOfWork = unitOfWork;
    }

    public GetCountry(int id)
    {
        return _unitOfWork.CountryRepository.GetById(id);
    }

    public GetProvince(int id)
    {
        return _unitOfWork.ProvinceRepository.GetById(id);
    }

    public void AddProvince(Province province)
    {
        _unitOfWork.ProvinceRepository.Create(province);
        Country country = GetCountry(province.CountryId);
        country.NumberOfProvinces++; // Update aggregate count
        _unitOfWork.Commit();
    }

    /* ... and so on ... */
}

这似乎需要做很多工作，但使用这种方法会使所有内容都松散耦合且可进行单元测试。我是否错过了更简单的方法，或者这是一个很好的方法if我要抽象出实体框架？

Answer 1

你应该永远不要抽象 ORM（它本身就是一个抽象），但你应该抽象 Persistence。我使用的唯一 UoW 是一个数据库事务，这是一个持久性细节。您不需要一起使用 UoW 和 Repository。你应该认为如果你真的需要所有这些东西。

就个人而言，我默认使用存储库，因为持久性是我在应用程序中做的最后一件事。我不关心模式本身，我关心的是我的 BL 或 UI 与 DAL 的分离。您的上层（除了 DAL 之外的所有层，从依赖关系的角度来看它是最低层）应该始终了解抽象，以便您可以在 DAL 实现中随心所欲地进行。

许多开发人员不知道的一个技巧是，设计模式（尤其是架构模式）应该首先被视为高级原则，其次才是技术诀窍。简而言之，最重要的是模式试图实现的好处（原则，大局），而不是其实际实现（“低级”细节）。

问问自己，为什么 BL 首先应该知道 UoW。 BL 只知道处理业务对象的抽象。而且您永远不会一次性使用整个 BL，您总是处于特定的 BL 上下文中。您的 DirectoryService 似乎在为自己的利益做很多事情。更新统计数据看起来与添加新省份不属于同一背景。另外，为什么您需要 UoW 进行查询？

我经常看到的一个错误是，当开发人员没有做最重要的部分：设计本身时，他们急于编写任何代码（附有设计模式）。当您的设计不正确时，就会出现问题，您开始寻找解决方法。其中之一是具有 Repository 属性的 UoW，它需要像 BL 这样的高层来了解更多的业务问题。现在 BL 需要知道您正在使用 UoW，这是一种较低级别的模式，对 DAL 来说很好，但对 BL 来说不太好。

顺便说一句，在处理“读取”情况时，UoW 对查询毫无意义，UoW 仅用于“写入”。我没有提到 EF 或任何 ORM，因为它们并不重要，您的 BL 服务（目录服务）已经被不当设计所需的基础设施细节破坏了。请注意，有时您确实需要妥协才能实施解决方案，但事实并非如此。

正确的设计意味着您了解有限的上下文（是的，无论您想执行多少 DDD，您都可以应用 DDD 概念）并且不要将可能使用相同数据的所有内容放在一个地方。您有用例的特定上下文，计算省份（演示/报告细节）实际上是与添加省份不同的用例。

添加省份，然后发布一个事件，向处理程序发出信号以更新统计数据是一种更优雅、可维护的解决方案。也不需要 UoW。

您的代码将如下所示

public class DirectoryService : IDirectoryService
{
     public DirectoryService(IProvinceRepository repo, IDispatchMessage bus) 
     { 
       //assign fields
     }

      /* other stuff */

      //maybe province is an input model which is used by the service to create a business Province?
      public void AddProvince(Province province)
     {

        _repo.Save(province);
        _bus.Publish( new ProvinceCreated(province));
     }
}

  public class StatsUpdater:ISubscribeTo<ProvinceCreated> /* and other stat trigger events */
   {
       public void Handle(ProvinceCreated evnt)
       {
              //update stats here
       }  
   }

在某种程度上它简化了事情，在其他方面你可能认为它使事情复杂化。实际上，这是一种可维护的方法，因为 stats updater 可以订阅 许多 事件，但逻辑只保留在一个类中。而且 DirectoryService 只做假设它做的事情（AddProvince 名称的哪一部分暗示您该方法也会更新统计信息？）。

总之，在急于使用 UoW、DbContext、存储库作为属性等使您的生活复杂化之前，您需要更好地设计 BL

Answer 2

或假设工作单元和存储库使用的 DbContext 是共享的，并且应该存在于整个 HTTP 请求中

这显然是错误的。假设上下文在 UoW 和存储库之间共享并不意味着上下文生存期应该取决于 HTTP 请求。相反 - 您可以创建上下文的新实例以及随时使用它的 UoW。这只是为 HTTP 请求提供 默认 UoW 的一种便利，但创建新的本地工作单元可能会很方便。

另一方面，如果存储库从 UoW 公开：

public class UnitOfWork
{
    ...

    public IUserRepository UserRepo
    {
        get { ... } 
    }

    public IAccountRepository AccountRepo
    {
        get { ... } 
    }

那么 not 在 repos 之间共享相同的上下文可能会产生意想不到的结果：

 UoW uow = ....

 var u1 = uow.User.FirstOrDefault( u => u.ID == 5 );
 var u2 = uow.Account.FirstOrDefault( a => a.ID_USER == 5 ).User;

您肯定希望这两个返回 ID 为 5 的用户的相同实例，更重要的是，共享相同的上下文意味着第二个查询可以从一级缓存中检索用户。另一方面，两个 repos 的两个不同上下文意味着你得到两个不同的实例。

这也意味着这是不可能的

 var u1 = uow.User.FirstOrDefault( u => u.ID == 5 );
 var a1 = uow.Account.FirstOrDefault( a => a.ID == 177 );

 a1.User = u1; // oops!

因为混合来自不同上下文的实体只会引发异常。但是上面的情况很常见！

从这些观察中得出的结论是，您应该在 repos 之间共享上下文。但是，如果您需要一个新的实例，您只需创建一个本地的、新的上下文实例，将其注入 UoW，然后再将其注入 repos，然后随意处置它。