Question

我搜索了一下，我很困惑。

First Approach使用Autofac为每个实体使用存储库和服务。工作单元类没有存储库。因此，您应该创建每个存储库，而不是仅在调用者构造函数中创建一个工作类单元。

OrderService(IUnitOfWork unitOfWork, IUserRepository userRepository,IOrderRepository orderRepository,IBalanceRepository balanceRepository)

Second Approach仅使用通用存储库。它使用扩展类，而不是为每个实体使用一个存储库。工作单元类具有通用存储库。因此，您可以在调用者类构造函数上创建工作类单元。

OrderService(IUnitOfWork unitOfWork)

在这种方法中，我们为存储库使用一个通用类，但我们为每个实体创建一个存储库对象。如果这种方法很好，我怎么能用Autofac实现呢？

Third Approach使用一个通用存储库和一个对象用于Autofac的通用存储库。它使用泛型方法而不是泛型类。但是通用存储库具有工作单元而不是相反。这是反模式吗？

OrderService(IUnitOfWork unitOfWork,IGenericRepository repository)

我应该使用哪种方法？

Answer 1

我使用第二个，IUnitOfWork只是一个界面，后面我使用ef。

public interface IUnitOfWork:IDisposable
{        
    IRepository<T> GetRepository<T>() where T:class;        
    int SaveChanges();
}

并创建dbcontext类

public class DataContext:DbContext,IUnitOfWork

实现GetRepository方法，您应该添加一个从dbset到irepository的适配器类

    public IRepository<T> GetRepository<T>() where T:class
    {
        return new RepositoryEfAdapter<T>(Set<T>(), this);
    }

这是一个示例，您可以将datacontext注册为iunitofwork

Answer 2

工作单元和存储库模式的意义在于准确描述例如用例所需的内容。因此，具有每个实体的存储库或可以通过泛型方法为任何实体创建存储库的工作单元同样可以避免，作为返回IQueryable的存储库。最后一个缺陷会将你的Dal移动到你的域模型甚至UI（想象一下编写过滤器逻辑的位置以及执行过滤器的时间以及抛出任何异常的位置），第一个创建一种单一的应用程序并使其变得困难编写单元测试。一个工作单元（接口）只有你的用例需要的3个存储库和只有所需方法的三个存储库（接口），返回一个对象或一个对象列表更容易模拟和测试并指定具体用例需要什么，并将其传达给您的开发人员（或2年内自己）。接口可以由一个工作类的大单元实现（如果你选择），也许还有一些标准的存储库类，但这是一个应该由技术引导的不同决策（早期版本中的EF代码首先无法实现）一个数据库中的多个上下文）和应用程序的复杂性。

Autofac存储库模式和工作单元

2 个答案: