Repository-Muster - Warum genau brauchen wir Schnittstellen?

So, wie Schnittstellen kommen ins Bild ?

Wie diese:

public interface IEmployeeRepository
{
    Employee[] GetAll();
}

und dann könnten Sie haben, wie viele Implementierungen, wie Sie möchten:

public class EmployeeRepositoryEF: IEmployeeRepository
{
    public Employee[] GetAll()
    {
        //here you will return employees after querying your EF DbContext
    }
}

public class EmployeeRepositoryXML: IEmployeeRepository
{
    public Employee[] GetAll()
    {
        //here you will return employees after querying an XML file
    }
}

public class EmployeeRepositoryWCF: IEmployeeRepository
{
    public Employee[] GetAll()
    {
        //here you will return employees after querying some remote WCF service
    }
}

and so on ... you could have as many implementation as you like

Wie Sie sehen können ist es nicht wirklich wichtig, wie implementieren wir das repository. Was wichtig ist, dass allen Repositorys und-Implementationen hinsichtlich der definierten Vertrag (interface) und alle besitzen ein GetAll Methode der Rückkehr eine Liste der Mitarbeiter.

Werden und dann haben Sie eine Steuerung, die diese Schnittstelle benutzt.

public class EmployeesController: Controller
{
    private readonly IEmployeeRepository _repository;
    public EmployeesController(IEmployeeRepository repository)
    {
        _repository = repository;
    }

    public ActionResult Index()
    {
        var employees = _repository.GetAll();
        return View(employees);
    }   
}

Sehen, wie sich der controller nicht mehr abhängig von einer bestimmten Implementierung der repository? Alle, die es wissen muss, ist, dass die Umsetzung dieser Hinsicht den Vertrag. Jetzt alles, was Sie tun müssen ist, konfigurieren Sie Ihre Lieblings-dependency injection-framework zu verwenden, die Implementierung, die Sie wünschen.

Hier ist ein Beispiel, wie dies mit Ninject:

1. Installieren Sie die Ninject.MVC3 NuGet

2. In der generierten ~/App_Start/NinjectWebCommon.cs code, den Sie einfach entscheiden, um die EF-Implementierung mit einer einzigen code-Zeile:

   private static void RegisterServices(IKernel kernel)
   {
       kernel.Bind<IEmployeeRepository>().To<EmployeeRepositoryEF>();
   }        

Diese Weise müssen Sie nicht mehr tun müssen keine manuellen Umschreibungen diejenigen repository-Klassen und sorgen machen upcasting oder was auch immer. Es ist das dependency-injection-framework verwaltet diese für Sie und kümmern sich um die Injektion der angegebenen Implementierung in das controller-Konstruktor.

Und einfach durch änderung dieser Konfiguration konnten Sie schalten Sie Ihr Daten-access-Technologie, ohne Sie zu berühren eine einzige Zeile code im controller. Das ist, wie unit-Tests in isolation kommt auch ins Spiel. Da Ihr controller-code ist jetzt schwach gekoppelt sind, um das repository (Dank der Schnittstelle, die wir eingeführt) alles, was Sie tun müssen, um in den unit-test ist einigen mock-Implementierung auf das repository, das können Sie definieren Ihr Verhalten. Dies gibt Ihnen die Möglichkeit, unit-Tests der Index-controller-action ohne Abhängigkeit von einer Datenbank oder was auch immer. Komplette isolation.

Ich auch Sie einladen, an der Kasse des folgende Artikel über TDD und DI in ASP.NET MVC.