asp.net – 为什么我要将UnitOfWork与Repository Pattern一起使

考虑到我可以通过使用DI来使我的存储库可测试,因为在What are best practices for managing DataContext这篇文章中建议使用IoC.我正在考虑将上下文作为对我的存储库构造函数的依赖进行处理,然后像这样处理它？

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应用程序推荐的内容相矛盾：

For web applications use single context per request. For web services use single context per call. In WinForms or WPF application use single context per form or per presenter. There can be some special requirements which will not allow to use this approach but in most situation this is enough.

查看完整的答案here

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

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