В контексте личного игрового проекта для получения дополнительной информации о шаблонах DDD мне не хватает объекта Specification. для моих фильтров.
Глядя на примеры, кажется, что все (например, LinQ) ориентировано на базы данных SQL. Однако во многих базах данных NoSQL для большинства запросов даже просто «выбрать * из таблицы» требуется предопределенное представление. Тем не менее, если репозиторий отображает веб-службу, даже тип запросов гораздо более жесткий.
Существуют ли варианты шаблона спецификации с учетом ограничений баз данных, отличных от SQL? У меня такое ощущение, что это потребует использования наследования и статических объявлений для поддержки различных типов бэкендов постоянства.
Как мне совместить «сортировку» и «фильтрацию» в моих репозиториях? В качестве примера рассмотрим репозиторий для списка элементов Order.
(Query)findAllSortedByDate;
(Query)findAllSortedByName;
(Query)findAllSortedByQuantity;
Таким образом, это разные типы сортировки при отображении в таблице. Поскольку я мог обрабатывать большие результаты, я никогда не рассматривал сортировку или фильтрацию в своих представлениях или моделях представлений. Сначала я подумал о классе Proyection, который выбирает правильный запрос из репозитория в соответствии с действиями пользователя. Однако это не работает, если я хочу комбинировать разные стратегии сортировки с разными фильтрами.
Очевидно, мне нужен какой-то объект "спецификации", но я не уверен, что:
- Должен ли я использовать их для своих репозиториев, делая их умнее? Или мне следует использовать их для моих моделей просмотра?
- Как правильно ограничить объекты моей спецификации для хорошей устойчивости полиглота?
Первоначально я думал о выполнении любого запроса с репозиторием, выступающим в качестве интерфейса, подобного коллекции но теперь я замечаю, что модель представления может также вести себя как интерфейс, подобный коллекции, с сохранением состояния, в то время как первые являются интерфейсами, подобными коллекции, без сохранения состояния.
- В целом, должен ли я пытаться сохранить какой-либо тип сортировки/фильтрации в моих репозиториях? Кажется, что это может добавить ненужной сложности, если все результаты запроса могут быть загружены в память.
ОБНОВЛЕНИЕ. Чтобы оживить этот вопрос, учтите также, что, хотя представления NoSQL можно фильтровать и сортировать, для полнотекстового поиска может потребоваться внешний механизм индексирования, такой как Lucene или SQLite-FTS, предоставляющий только уникальный идентификатор Сущности для запроса, которые необходимо снова отсортировать и отфильтровать.