4

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

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

4

1 回答 1

7

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

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 并将其提供给服务的代码必须更改，但这是另一段历史） . 这样，无论在何处读取/保存数据，相同的服务都可以正常工作。
于 2013-10-12T00:16:54.430 回答