Конкретный смысл IRepository<T> vs Repository, если я не делаю модульные тесты с макетами

Question

У меня есть это:

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

теперь для каждого моего Entity я делаю конкретные классы, реализующие универсальный IRepository =>

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

В моем конструкторе ViewModel (шаблон mvvm) я делаю это =>

IRepository<Schoolclass> repo = new SchoolclassRepository();

Какое преимущество имеет IRepository, когда у меня есть возможность написать код для моих операций CRUD в каждом классе сущностей?

В Customer, Product, Pupil любого класса, который я реализую IRepository<Product>, IRepository<Customer>, IRepository<Pupil> и т.д... и я реализую методы интерфейса.

Почему я не мог сказать =>

SchoolclassRepository repo = new SchoolclassRepository(); ??? 

Мне не важно иметь возможность писать модульные тесты для небольшого приложения.

Answer 1

Шаблон репозитория основан на IoC и шаблонах внедрения зависимостей, просто для модульного тестирования требуется IoC и внедрение зависимостей, чтобы упростить тестирование. Изначально он не был предназначен для написания слоя доступа к данным, хотя многие публикуют и реализуют его как таковой. Для небольших приложений это зависит от того, сколько усилий вы хотите приложить.

Обычно реализация SchoolclassRepository будет находиться в отдельном пространстве имен от интерфейсов IRepository, поэтому вы можете поддерживать несколько реализаций. (Не правило)

Вы можете установить свою ViewModels constructor (mvvm pattern) to take a parameter for the repository interface IRepository<Schoolclass>. Now your ViewModelКонструктор s основан на интерфейсе, а не на реализации.

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

Почему вышеупомянутое....

Шаблон также облегчает внесение будущих изменений.

Если ваша реализация SchoolclassRepository() использовала ADO.NET (sqlconnections, sqlcommands...) для доступа к данным, вы можете позже создать другую SchoolclassRepository(), которая использует NHibernate, Entity Framework или какой-либо другой метод доступа к данным. Теперь все, что вам нужно сделать, это изменить ваших потребителей на использование целевой реализации и внедрить их в ViewModel.

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

Это просто краткий обзор использования, я бы рекомендовал продолжить изучение шаблона хранилища и того, как заставить его работать на вас. Вы, очевидно, заинтересованы в этом, что это хорошо.