Я довольно долго искал хорошее решение проблем, связанных с типичным шаблоном репозитория (растущий список методов для специализированных запросов и т. Д., См .:http://ayende.com/blog/3955/repository-is-the-new-singleton).

Мне очень нравится идея использования командных запросов, особенно с помощью шаблона спецификации. Однако моя проблема со спецификацией заключается в том, что она относится только к критериям простого выбора (в основном, к предложению where) и не связана с другими вопросами запросов, такими как объединение, группировка, выбор подмножества или проекция и т. Д. в основном, все лишние обходы, через которые должны пройти многие запросы, чтобы получить правильный набор данных.

(примечание: я использую термин «команда», как в шаблоне «Команда», также называемом объектами запроса. Я не говорю о команде, как в разделе «команда / разделение запросов», где существует различие между запросами и командами (обновление, удаление, вставить))

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

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

Я ищу решения, которые могут быть разработаны другими для решения этой проблемы или для решения другой проблемы, но все же удовлетворяет этим требованиям. В связанной статье Ayende предлагает использовать контекст nHibernate напрямую, но я чувствую, что это значительно усложняет ваш бизнес-уровень, поскольку теперь он также должен содержать информацию о запросах.

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

ПРИМЕЧАНИЕ: я ищу что-то на основе ORM. Не обязательно должен быть явно EF или nHibernate, но они наиболее распространены и подходят лучше всего. Если его можно легко адаптировать к другим ORM, это будет бонусом. Совместимость с Linq тоже подойдет.

ОБНОВЛЕНИЕ: я действительно удивлен, что здесь не так много хороших предложений. Кажется, что люди либо полностью CQRS, либо они полностью в лагере репозитариев. Большинство моих приложений не достаточно сложны, чтобы гарантировать CQRS (что-то, с чем большинство сторонников CQRS с готовностью говорят, что вы не должны использовать его для).

ОБНОВЛЕНИЕ: Здесь, кажется, небольшая путаница. Я не ищу новую технологию доступа к данным, а скорее разумно разработанный интерфейс между бизнесом и данными.

В идеале то, что я ищу, - это нечто среднее между объектами Query, шаблоном Specification и хранилищем. Как я уже говорил выше, шаблон спецификации имеет дело только с аспектом предложения where, а не с другими аспектами запроса, такими как объединения, подвыборы и т. Д. Репозитории обрабатывают весь запрос, но через некоторое время выходят из-под контроля. , Объекты запросов также имеют дело со всем запросом, но я не хочу просто заменять репозитории взрывами объектов запросов.