为什么在使用实体框架实现存储库模式时使用接口？

Question

在结合实体框架实现存储库模式时，为什么我看到许多示例使用其存储库类的接口？一个具体的参考例子是here。

界面的意义何在？为什么不只是课堂？真的需要不止一个类来订阅那个非常具体的接口吗，例如只针对员工？

Answer 1

这是一种经常使用的模式，经常专门用于单元测试，而不是真正特定于实体框架或存储库模式，甚至任何数据访问类型。另一个很大的好处是，它使后者有机会在不更改使用它的代码的情况下提供替代实现。 以这段代码为例，它使用dependency injection 模式：

public class EmployeeService
{
    private readonly IEmployeeRepository employeeRepository;

    public EmployeeService(IEmployeeRepository employeeRepository)
    {
        this.employeeRepository=employeeRepository;
    }

    public IEnumerable<Employee> GetAllEmployees()
    {
        IEnumerable<Employee> employeeList=this.employeeRepository.GetAll();
        //Optionally do some processing here
        return employeeList;
    }
}

通过在存储库中拥有接口，请注意，您现在可以完全使用该接口工作，而无需提及实际的存储库，这就是它的真正价值。它主要有两个好处：

• 如果你想为这个类编写一个自动化的单元测试，你可以给它一个IEmployeeRepository的假实现，它不会进入真正的数据库，而是返回一个硬编码的列表，这样你就可以测试你的方法现在不用担心数据库。这被称为“模拟”，通常是将接口放在那里的主要原因。还有几个库可以自动执行该过程，所有这些库都依赖于它们生成一个实现接口的假类这一事实。到目前为止，这是放置这样一个界面的最常见原因。
• 您可能会决定在未来某个时候用其他东西替换实体框架，或者说，想要为不同于关系数据库的东西实现存储库。在这种情况下，您将编写另一个存储库，实现完全相同的接口，但做一些完全不同的事情。鉴于使用它的服务仅依赖于接口，只要遵守相同的合同（当然，实际创建 repo 的代码并将其提供给服务必须更改，但这是另一段历史）。这样，无论在何处读取/保存数据，相同的服务都可以正常工作。