为什么我要将UnitOfWork与Repository Pattern一起使用？

Question

我在网上看到了很多关于UnitOfWork和Repo Pattern的内容,但仍然没有清楚地了解为什么以及何时使用 - 这对我来说有点混乱.

考虑到我可以通过使用DI来使我的存储库可测试,如本文所述,使用IoC 什么是管理DataContext的最佳实践.我正在考虑将上下文作为对我的存储库构造函数的依赖进行传递,然后像这样处理它？:

public interface ICustomObjectContext : IDisposable {}
public IRepository<T> // Not sure if I need to reference IDisposable here
public IMyRepository : IRepository<MyRepository> {}

public class MyRepository : IMyRepository
{
    private readonly ICustomObjectContext _customObjectContext;

    public MyRepository(ICustomObjectContext customObjectContext)
    {
        _customObjectContext = customObjectContext;
    }

    public void Dispose()
    {
        if (_customObjectContext != null)
        {
            _customObjectContext.Dispose();
        }
    }

    ...

}

我目前对使用UnitOfWork和Repository Pattern的理解是在多个存储库中执行操作 - 这种行为似乎与@Ladislav Mrnka为Web应用程序推荐的内容相矛盾:

对于Web应用程序,每个请求使用单个上下 对于Web服务,每次调用使用单个上下文.在WinForms或WPF应用程序中,每个表单或每个演示者使用单个上下文.可能有一些特殊要求不允许使用这种方法,但在大多数情况下这已经足够了.

请在此处查看完整的答案

如果我理解正确的话,DataContext应该是短暂的,并且可以在每个请求或演示者的基础上使用(在其他帖子中也可以看到).在这种情况下,repo对上下文执行操作是合适的,因为范围仅限于使用它的组件 - 对吗？

我的回购在IoC中注册为瞬态,因此我应该为每个请求获得一个新的回购.如果这是正确的,那么我应该为每个请求获取一个新的上下文(上面的代码),然后处理它 - 说... 如果我关注,为什么我会将UnitOfWork模式与存储库模式一起使用上面的约定？

Answer 1

据我所知,工作单元模式不一定涵盖多个上下文.它只是封装了一个单一的操作或 - 井 - 工作单元,类似于一个事务.

创建你的上下文基本上开始了一个工作单元; 打电话DbContext.SaveChanges()结束了.

我甚至可以说,在其当前的实现中,Entity Framework的DbContext/ ObjectContext类似于存储库模式和工作单元模式.