4

リポジトリー・パターンをエンティティー・フレームワークと組み合わせて実装する場合、リポジトリー・クラスのインターフェースを使用する多くの例が見られるのはなぜですか? この参照の具体例はこちらです。

インターフェイスのポイントは何ですか？なぜクラスだけではないのですか？たとえば、従業員だけのために、その非常に特定のインターフェイスをサブスクライブする複数のクラスが本当に必要ですか?

4

1 に答える 1

7

これは頻繁に使用されるパターンであり、特に単体テストに使用されることが非常に多く、エンティティ フレームワークやリポジトリ パターン、さらにはデータ アクセスの種類に固有のものではありません。もう 1 つの大きな利点は、それを使用するコードを変更することなく、代替実装を後で提供する機会が得られることです。たとえば、依存性注入パターンを使用する次のコードを考えてみましょう。

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;
    }
}

リポジトリにインターフェイスを配置することで、実際のリポジトリについて言及することなく、インターフェイスを使用して完全に作業できることに注意してください。これがその真の価値です。主に次の 2 つの利点があります。

  • このクラスの自動化された単体テストを作成する場合はIEmployeeRepository、実際のデータベースにはアクセスせず、代わりにハードコードされたリストを返す の偽の実装を与えることができます。とりあえずDB。これは「モック」と呼ばれ、多くの場合、そのインターフェイスを配置する主な理由です。そのプロセスを自動化するライブラリもいくつかありますが、これらはすべて、インターフェイスを実装する偽のクラスを生成するという事実に依存しています。これは、そのようなインターフェースを配置する最も一般的な理由です。
  • 将来、エンティティ フレームワークを別のものに置き換えたり、たとえば、リレーショナル DB とは異なるものにリポジトリを実装したりすることを決定する場合があります。この場合、まったく同じインターフェースを実装する別のリポジトリを作成しますが、まったく異なることを行います。それを使用するサービスがインターフェイスのみに依存していることを考えると、同じコントラクトが尊重されている限り、コードはまったく変更されずに機能します (もちろん、実際にレポを作成してサービスに渡すコードは変更する必要がありますが、それは別の歴史です) . そうすれば、データの読み取り/保存場所に関係なく、同じサービスが同じように機能します。
于 2013-10-12T00:16:54.430 に答える