Що ж, ви можете побачити хороший приклад у Spring Data Framework, який базується на концепції сховищ.
Там ви побачите, що сховища мають справу лише зі сховищем даних і рідко містять ділову логіку (це зарезервовано для сервісного рівня). Так, наприклад, ви подивіться на їх дизайн, побачите, що у них є інтерфейс CRUDRepository, який розкриває методи створення, знищення та відновлення об'єктів (серед іншого). Існує також PagingAndSortingRepository, який додає додаткову функціональність саме для цього, сортування та підкачки результатів тощо, тощо, тощо.
Отже, ця рамка, можливо, є гарним місцем для вивчення гарного дизайну сховищ.
Наскільки мені відомо, багато концепцій, впроваджених Spring Data Framework, походять з чудової книги під назвою Дизайн, керований доменом: Рішення складності в серці програмного забезпечення , книга має цілий розділ, присвячений дизайну репозиторію.
Ви можете розглянути можливість отримання його копії.
Невеликий уривок із книги пояснює:
Шаблон РЕПОЗИТОРІЇ - це проста концептуальна основа для інкапсуляції цих рішень та повернення фокусу нашої моделі.
РЕПОЗИТОРІЯ представляє всі об'єкти певного типу у вигляді концептуального набору (як правило, емульованого). Він діє як колекція, за винятком більш детальної можливості запиту. Об'єкти відповідного типу додаються та видаляються, а техніка, що стоїть за РЕПОЗИТОРІєю, вставляє їх або видаляє їх із бази даних. Це визначення збирає злагоджений набір обов'язків щодо забезпечення доступу до коренів АГРЕГАТІВ від раннього життєвого циклу до кінця.
Клієнти запитують об'єкти з REPOSITORY, використовуючи методи запитів, які вибирають об'єкти на основі критеріїв, визначених клієнтом, як правило, значення певних атрибутів. РЕПОЗИТОРІЯ отримує запитуваний об'єкт, інкапсулюючи механізми запитів баз даних та відображення метаданих. РЕПОЗИТОРІЇ можуть реалізовувати різноманітні запити, які вибирають об'єкти за будь-якими критеріями, які вимагає клієнт. Вони також можуть повернути підсумкову інформацію, наприклад, підрахунок, скільки примірників відповідає деяким критеріям. Вони можуть навіть повернути підсумкові обчислення, такі як загальна сума для всіх об'єктів, що відповідають деякому чисельному атрибуту.
РЕПОЗИТОРІЯ знімає величезний тягар з клієнта, який тепер може поговорити з простим інтерфейсом, який розкриває намір, і запитати, що йому потрібно з точки зору моделі. Для підтримки всього цього потрібно багато складної технічної інфраструктури, але інтерфейс простий і концептуально підключений до доменної моделі.
Тому:
Для кожного типу об’єктів, які потребують глобального доступу, створіть об’єкт, який може створювати ілюзію колекції в пам'яті всіх об'єктів цього типу. Налаштуйте доступ через відомий глобальний інтерфейс.
Надайте способи додавання та видалення об’єктів, які будуть інкапсулювати фактичне вставлення або видалення даних у сховищі даних. Надайте методи, що вибирають об’єкти на основі деяких критеріїв і повертають повністю інстанційні об'єкти або колекції об'єктів, значення атрибутів яких відповідають критеріям, тим самим інкапсулюючи фактичну технологію зберігання та запитів. Надайте РЕПОЗИТОРІЇ лише для корінців AGGREGATE, які фактично потребують прямого доступу. Тримайте клієнта зосередженим на моделі, делегуючи всі об’єкти зберігання та доступ до REPOSITORIES.