вопрос разработки уровня запросов / отчетов (DDD / CQRS)

Question

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

мой вопрос заключается в том, должен ли я просто разрешить своим контроллерам прямой доступ к моему IQueryContext, который просто существенно абстрагирует контекст EF.или мне следует создать службу запросов в стиле сценариев транзакций, например ICustomerQueries, которая содержит все связанные методы отчетности?или, может быть, каждый запрос имеет свою концепцию и живет в своем собственном объекте, т.е.GetProductsByCustomerQuery

любая помощь / идеи / аргументы будут великолепны!

Answer 1

Я бы держал сторону запроса как можно более простой.Вероятно, меня это заслужит, но, на мой взгляд, может оказаться достаточно приблизиться к сырому SQL, насколько это возможно, в некоторых случаях даже до SELECT * FROM ....

Таким образом: представьте свои сглаженные представления -- а затем ваши денормализованные таблицы - через EF или Linq2SQL и связать их с вашим пользовательским интерфейсом (я бы даже зашел так далеко и поставил под сомнение необходимость ORM на данном этапе).Никаких дополнительных уровней абстракции не требуется.Экономит время, чтобы сосредоточиться на базовом домене.

Answer 2

Я склонен использовать службы данных WCF на стороне запроса. Итак, у меня есть модель Entity Framework базы данных Read, затем поверх нее создается служба данных WCF (это занимает всего несколько минут), а затем выполняется запрос к этой службе данных WCF.

Это просто, это согласованно, вы можете настроить его для доступа только для чтения, оно поддерживает LINQ и даже протокол OData, так что вы можете писать запросы в своем URL.

Смотри также:

• OData: http://www.odata.org/
• Службы данных WCF: http://msdn.microsoft.com/en-us/data/bb931106