Ответ шаблона репозитория на сложные / немодельные специфические запросы (т. Е. Отчеты / сводные данные)

Question

Я читал о шаблоне репозитория и изо всех сил пытался найти надежный ответ о том, как люди подходят к ситуациям, когда возвращаемые данные - это не только ваши стандартные модели (т.е. НЕ Customer 1..* Account)

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

В прошлом я просто создавал свой запрос и возвращал результаты в виде пользовательского набора результатов (если это давало доступ к ORM из моих верхних уровней моей системы и, таким образом, не отделяло мою систему от знания об используемом ORM),

Шаблон репозитория здесь не очень подходит? Как другие подошли к этому типу сценария? Это похоже на квадратный колышек / круглое отверстие.

Для справки, я разрабатываю на C# .Net с использованием ASP MVC с MSSQL DB.

ОБНОВИТЬ

Хотя мой сценарий в значительной степени основан на отчетах, я все еще имею дело с отдельными сущностями, которые составляют данные, на которых основаны отчеты.

Как (просто) пример: мне все еще нужны мои Customer юридическое лицо, и этот клиент все еще должен иметь Orders что они генерируют через систему. Мой домен POCOS хорошо работает здесь, в этом сценарии. Вопрос возникает после получения МНОГО Orders и необходимость составлять отчеты по ним вместе со многими объединенными агрегированными таблицами в формате, который не совпадает нигде рядом с моими существующими объектами домена.

Answer 1

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

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