Структура классов шаблона Repository

Делал блог по этом примеру
Хотел бы разобраться структуре классов шаблона, не совсем понял рисунок ниже.
Зачем вообще реализовывать все это через шаблон Repository, эти все интерфейсы, классы для представления модели и т. п.
Почему не можно просто использовать один из принципов Entity Framework (Model First, Code First, DataBase Fisrt), а потом создать соответственно Контролер под Модель, и его представления??? Я вроде бы архитектуру MVC понимаю, а вот как работать с ней походу не понимаю(((((

Миниатюры

 

0

- Репозитории используются для сокрытия в себе часто используемой логики обращений к базе данных, ведь чаще всего это вызов не одного метода, кроме того, очень часто надо дополнительно делать различные проверки, а дублировать код не есть хороший подход. В добавок, пользователь этого репозитория не может сделать некорректное действие, так как он находится на один уровень абстракции выше. Т.е., к примеру, для создания нового комментария к посту достаточно написать что-то вида:
Текущую дату передавать не нужно, так как метод сам ее указывает. Просто и понятно. Дополнительно можно добавить необходимую логику для случая, когда добавить новый комментарий не удалось. Думать дополнительно о том, какой запрос к базе данных писать, не нужно, даже если он и сводиться к банальному вызову хранимой процедуры. Если же вдруг закралась ошибка в реализации создания нового комментария, то достаточно изменить один метод, а не бегать по всему проекту и искать место, где код создает новый комментарий, да таких мест может быть много.
- Используется принцип разделения ответственности - каждый репозиторий отвечает за свою сущность, что облегчает понимание и сопровождение кода. К тому же, зайдя, к примеру, в репозиторий для тех же комментариев, можно увидеть наглядно все методы в одном месте, которые взаимодействуют именно с таблицей комментариев. В случае модификации этой таблицы, легко быстро подправить все нужные методы.
- Наличие интерфейса для каждого репозитория вместе с каким-либо IoC (например, Unity) помогает в модульном тестировании (легко подсунуть вместо нужного класса заглушку/фейк и проверить поведение программы в форс мажорных ситуациях).
- Один программист может писать слой доступа к данным (репозитории), другой же на основе интерфейсов репозиториев последующую бизнес-логику.
И да, репозитории не создаются для повторения в них CRUD-функций.
Подытожив, если проект большой, репозитории унифицируют логику, облегчают понимание кода и процесс тестирования, иначе же использовать репозитории и подавно IoC - излишне.
P.S. А ведь есть еще Unit of Work. (:

2

Сообщение от I2um1 И да, репозитории не создаются для повторения в них CRUD-функций.

Т.е. CRUD-функции должны быть непосредственно в методах репозитория, я правильно понял?

0

Сообщение от iPhonia Т.е. CRUD-функции должны быть непосредственно в методах репозитория, я правильно понял?

да, вы правильно поняли, то есть ту пару строк на добавление или изменения с помощью контекста данных вы вкладываете в метод класса репозитория

1