В настоящее время я работаю над приложением MVC 4. Я планирую реализовать шаблон разделения командных запросов для повышения производительности и структуры приложения. Я доволен своими командами, которые сопоставляют мои модели представлений с моими объектами, а затем используют nhibernate для сохранения моих данных. Команды и запросы будут выполняться из одной и той же базы данных.
Я немного не уверен в лучшем подходе к управлению моими запросами. В моем последнем проекте я использовал хранимые процедуры для всех своих операций чтения/запросов, а затем использовал automapper для сопоставления моих IDataReaders с моими ViewModels. Это работало нормально, но основная проблема заключалась в том, что время оборота для написания хранимых процедур, а также когда модель домена менялась, хранимые процедуры не синхронизировались.
Поэтому в идеале я хотел бы что-то, что автоматически генерировало представления или sprocs из моих моделей представлений. Но на самом деле я не вижу способа сделать это. Поскольку Sprocs/Views нуждаются в некотором знании потенциально более чем одной таблицы. Так что простого отражения свойств модели View будет недостаточно. Я мог бы автоматически сгенерировать таблицу для каждой модели представления, прочитать ее во время разработки, а затем, когда домен станет стабильным, и прежде чем мы отправимся в тестирование, преобразовать их в представления/sprocs?
Итак, я думаю, что я спрашиваю:
- Кому-нибудь удалось решить проблему автоматической генерации sproc/view, описанную выше? (это был бы мой любимый результат!) Или, что еще лучше, разработал гораздо более изящное решение!
- Или более разумно реализовывать необработанные чтения ADO только там, где они абсолютно необходимы, т. Е. Поиски, и избавляться от необходимости множества sprocs/views. Но потом все равно выделяю мои запросы в отдельный канал (но внутри одни используют NHibernate, а другие используют мой ADO-ридер).
(ps я просмотрел другие вопросы, связанные с CQS stackoverflow, и я надеюсь, что мой достаточно отличается, чтобы оправдать этот вопрос)