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

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

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

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

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

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

(ps я просмотрел другие вопросы, связанные с CQS stackoverflow, и я надеюсь, что мой достаточно отличается, чтобы оправдать этот вопрос)


person jonho    schedule 01.06.2013    source источник


Ответы (1)


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

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

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

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

введите здесь описание изображения

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

person JefClaes    schedule 03.06.2013
comment
исторически у нас были некоторые очень плохо выполняющиеся запросы NH, которые со временем ухудшались. Таким образом, подход Sproc состоял в том, чтобы улучшить это. Я также заинтересован в гибкости, которую предлагают отдельные команды и запросы. Мне нравится ваше предложение сгладить модель домена после сохранения и написать эти таблицы запросов. Я собираюсь изучить это. На данном этапе это может быть просто в том же процессе. Спасибо. - person jonho; 03.06.2013