Repository — патерн, який розділяє рівні джерела даних і логіки програми. Часто використовується із патерном Unit Of Work
Переваги та недоліки
Переваги Використовується, як колекція Інкапсулює великі запити до БД в методи Рівень абстракції між Business Logic рівнем та Data Access рівнем Ізолює програму від змін джерела даних Джерело даних може бути змінено без будь-яких змін в бізнес логіці і з мінімальними змінами в Репозиторії Полегшує автоматизоване юніт тестування, Test Driven Development Легко створювати mock репозиторію
Недоліки Зростає кількість класів Погіршує продуктивність Обмежує у використанні особливостей ОРМ фреймворку
Опис мовою C#
Використаємо Entity Framework. Нехай дано клас-сутність User
Тепер напишемо інтерфейс репозиторію. Варто зазначити, що репозиторій є колекцією, і має поводитись як колекція, та не містити методів , тощо. Також однією із великих помилок, є те що методи повертають замість . Якщо повертати це дозволить надбудувати над запитом, ще запити, що не є вірним, оскільки мета цього патерну якраз і є уникнення великих запитів. В такому разі, краще написати ще один метод, який буде виконувати більший запит.
Тепер реалізуємо цей інтерфейс у вигляді узагальненого класу. При реалізації ми повертаємо сутність, а не DTO. Мапування — це не відповідальність репозиторію.
Тепер залишилось для кожної сутності реалізувати свій репозиторій. Напишемо інтерфейс, який додаватиме (а можливо і ні) новий функціонал для конкретного репозиторію.
Та конкретна реалізація:
При потребі варто також узагальнювати тип ключа:
Зв'язок з іншими патернами Unit Of Work та Repository часто використовують в парі.
Реалізація
Див. також Шаблони проєктування програмного забезпечення Об'єктно-орієнтоване програмування
Джерела Implementing the repository and unit of work patterns Repository and unit of work pattern Common mistakes with the repository pattern