Запросы CQS - Автоматическое создание ADO для отображения моделей?

Question

В настоящее время я работаю над приложением MVC 4. Я планирую реализовать шаблон разделения запросов для повышения производительности и структуры приложения. Я доволен своими командами, которые отображают мои модели взглядов для моих объектов, а затем используют nhibernate для сохранения моих данных. Команды и запросы будут работать с той же базой данных.

Я немного не уверен в лучшем подходе к управлению своими запросами. В моем последнем проекте я использовал хранимые процедуры для всех своих чтений/запросов, а затем использовал automapper для сопоставления своих IDataReaders с моими представлениями. Это работало нормально, но основная проблема заключалась в том, чтобы развернуть время хранения хранимых процедур, а также, когда модель домена изменила хранимые процедуры, полученные из синхронизации.

Поэтому, в идеале, мне хотелось бы что-то, что автоматически генерирует виды или sprocs из моих моделей. Но реалистично, я не вижу способа сделать это. Поскольку Sprocs/Views нуждаются в некотором знании потенциально большего количества одной таблицы. Поэтому простое отражение свойств модели View будет недостаточно. Я мог бы автоматически генерировать таблицу для каждой модели представления, читать ее во время разработки, а затем, когда домен был стабильным и перед тем, как мы отправились тестировать, преобразуйте их в views/sprocs?

Так что я думаю, что я спрашиваю:

1. Кто-нибудь удалось решить проблему sproc/вид авто поколения, который я описал выше? (это было бы моим любимым результатом!) Или даже лучше разработало гораздо более изящное решение!
2. Или более разумно только реализовать необработанные ADO-чтения, где они абсолютно необходимы - например, поиск и отсутствие необходимости в большом количестве sprocs/views. Но потом все еще выделяйте свои запросы на отдельный канал (но внутри некоторых из них они используют NHibernate, в то время как другие используют мой ADO-ридер).

(p.s я смотрел на других StackOverflow ОКК связанных с этим вопросов, и я надеюсь, что у меня это достаточно разные, чтобы оправдать этот вопрос)

Answer 1

Что хранимые процедуры решить для вас? Почему вы не можете использовать NHibernate для чтения тоже? Являются ли запросы NHibernate настолько плохими?

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

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

Поскольку картина говорит больше, чем тысяча слов ..

Вы можете прочитать хорошее введение в CQRS here.