Konkreter Sinn von IRepository<T> vs. Repository, wenn ich keine Unit-Tests mit Mocks durchführe

Question

Ich habe das hier:

public interface IRepository<T> where T : class
{
    void Delete(T entity);
    void Add(T entity);
    void Attach(T entity);
    void Detach(T entity);
    void SaveChanges();
}

Jetzt mache ich für jede meiner Entitäten konkrete Klassen, die das generische IRepository implementieren =>

public class SchoolclassRepository : IRepository<Schoolclass>
{
    public void Delete(Schoolclass entity)
    {
        throw new NotImplementedException();
    }

    public void Add(Schoolclass entity)
    {
        throw new NotImplementedException();
    }

    public void Attach(Schoolclass entity)
    {
        throw new NotImplementedException();
    }

    public void Detach(Schoolclass entity)
    {
        throw new NotImplementedException();
    }

    public void SaveChanges()
    {
        throw new NotImplementedException();
    }
}

Im Konstruktor meines ViewModels (mvvm-Muster) mache ich folgendes =>

IRepository<Schoolclass> repo = new SchoolclassRepository();

Welchen Vorteil bietet IRepository, wenn ich den Code für meine CRUD-Operationen ohnehin in jeder Entitätsklasse schreiben muss?

In den Klassen Customer, Product, Pupil implementiere ich die IRepository<Product> , IRepository<Customer> , IRepository<Pupil> usw... und ich implementiere die Methoden der Schnittstelle.

Warum konnte ich nicht sagen =>

SchoolclassRepository repo = new SchoolclassRepository(); ??? 

Ich möchte nicht die Möglichkeit haben, Unit-Tests für eine kleine Anwendung zu schreiben.

Answer 1

Das Repository-Muster basiert auf IoC- und Dependency-Injection-Mustern. Unit-Tests benötigen zufällig IoC und Dependency-Injection, um das Testen zu erleichtern. Ursprünglich war es nicht dazu gedacht, eine weitere Möglichkeit zum Schreiben der Datenzugriffsschicht zu sein, obwohl viele es als solche veröffentlichen und implementieren. Bei kleinen Anwendungen hängt es davon ab, wie viel Aufwand Sie betreiben wollen.

Normalerweise wird die Implementierung SchoolclassRepository in einem separaten Namespace von den IRepository-Schnittstellen liegen, damit Sie mehrere Implementierungen unterstützen können. (Keine Regel)

Sie können Ihr ViewModel s constructor (mvvm pattern) to take a parameter for the repository interface IRepository<Schoolclass>. Now your ViewModel s Konstruktor basiert auf der Schnittstelle und nicht auf der Implementierung.

private IRepository<Schoolclass> _repository
public ViewModel(IRepository<Schoolclass> Repository) 
{ this._repository = Repository; }

Warum werden die oben genannten ....

Das Muster erleichtert auch künftige Änderungen.

Wenn Ihre Implementierung von SchoolclassRepository() ADO.NET (sqlconnections, sqlcommands...) für den Datenzugriff verwendet, können Sie später ein anderes SchoolclassRepository() erstellen, das NHibernate, Entity Framework oder eine andere Datenzugriffsmethode verwendet. Jetzt müssen Sie nur noch Ihre Konsumenten so ändern, dass sie die angestrebte Implementierung verwenden, und sie in das ViewModel injizieren.

Repository repository = new ADONET.SchoolclassRepository(); 
or
Repository repository = new EntityFramework.SchoolclassRepository(); 
ViewModel viewmodel = new ViewModel(repository);

Dies ist nur ein kurzer Einblick in die Verwendungsmöglichkeiten. Ich empfehle, das Repository-Muster weiter zu studieren und herauszufinden, wie man es für sich selbst nutzen kann. Sie sind offensichtlich daran interessiert, die es gut.