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