конкретный смысл IRepository <T>против репозитория, если я не делаю модульные тесты с макетами - PullRequest
Новая
       41

конкретный смысл IRepository <T>против репозитория, если я не делаю модульные тесты с макетами

3 голосов
/ 18 февраля 2010

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

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

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

1 Ответ

4 голосов
/ 18 февраля 2010

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

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

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

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

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

...