为什么在我使用带有依赖项注入的接口时GenericRepository返回一个类？

Question

我正在使用C＃、. NET Framework 4.5，实体框架6.1.0 Code First和Ninject开发ASP.NET MVC 5 Web API。

为此，我使用通用存储库 ， 工作单元和依赖注入模式（至少，我正在尝试遵循它们）。

我有以下项目：

• MyProduct.Domain

• 我的产品。接口

• MyProduct.WebAPI

在MyProduct.Interfaces我有两个接口：

• IGenericRepository
• IUnitOfWork

在MyProduct.Domain我有三个文件夹：

• Concrete包括以下类： EFDbContext ， GenericRepository （实现IGenericRepository ）和UnitOfWork （实现IUnitOfWork ）。
• Configurations与EF代码优先配置。
• 具有表示数据库表的类的Entities 。

这是我的IUnitOfWork接口：

public interface IUnitOfWork
{
    void SaveChanges();
    IRepository CustomerRepository { get; }
    IRepository ProductRepository { get; }
    IRepository OrderRepository { get; }
}

以及带有构造函数注入的控制器：

private IUnitOfWork unitOfWork;

public OrderController(IUnitOfWork unitOfWork )
{
    this.unitOfWork = unitOfWork;
}

现在我的问题是：

如果我通过UnitOfWork.CustomerRepository.GetAll();获得所有客户， 。

这将返回IEnumerable<Customer>和Customer它在MyProduct.Domain定义。 那是对的吗？

我正在尝试解耦MyProduct.WebApi上的任何实体框架引用，但是如果我必须添加对Customer的引用（在MyProduct.Domain ，folder Entities定义），我不会解耦任何东西，因为我正在引用MyProduct.Domain项目。

也许我在这里什么都不懂，因为我不明白为什么我要使用IUnitOfWork接口，然后在控制器的任何操作下，我都有一个MyProducts.Domain的类的实例。

我是否需要将实体移动到另一个项目，例如MyProduct.Model ？

Answer 1

那是您必须做出的选择，将所有实体移至另一个项目都没有关系。 但就我而言，我总是这样做。

如果您有疑问，这里有一个如何实现GenericRepository的想法如何在EF6代码优先中与数据库上下文一起使用泛型类型

Answer 2

出于多种原因，在您的应用程序中使用工作单元和存储库绝对是一个好主意。 但是，这并不意味着您必须创建自己的工作单元和存储库。

实体框架的DbContext已经是一个工作单元，并且所包含的DbSet已经是通用存储库。 因此，除了使用EF外，什么也不做就已经满足了良好做法。

绝对会有很多人指向用于单元测试的存储库。 但是，从EF6开始，您现在可以对EF上下文进行适当的模拟，以进行单元测试。 如果您绝对想将其抽象出来，请使用具体的存储库。

创建自己的UnitOfWork类的唯一原因是两个原因之一。 1）您打算替换您的数据库技术。 或2）您正在使用未实现UnitOfWork的数据库技术（即ADO.NET或其他）。

就＃1而言...

大多数人认为他们可能会替换其数据库技术，但这几乎永远不会发生。 如果这样做的话，很可能您已经让太多的实现细节泄漏到您的设计中，以至于永远都不会轻易换掉。

对于至少95％的使用自定义通用UnitOfWork /存储库的人来说，这只是多余的工作。 对于获得5％的收益，可能有更好的方法来获得相同的收益。

至于＃2 ...

如果您没有使用已经实现UnitOfWork的ORM或其他技术，那么您绝对应该自己实现。