CQS queries - Auto generate ADO Mapping to View models?

Question

I am currently working on an MVC 4 application. I am planning to implement a command query seperation pattern to enhance performance and the structure of the application. I am happy with my commands - which map my view models to my entities use then use nhibernate to save my data. The commands and queries will be running off the same database.

I am a bit unsure of the best approach to manage my queries. In my last project I used Stored procedures for all of my reads/queries, then used automapper to map my IDataReaders to my ViewModels. This worked ok but the main problem was the turn around time of writing the stored procedures and also when the domain model changed the stored procedures got out of sync.

Therefore, ideally I would like something that auto generated the views or sprocs from my view models. But realistically, I cannot see a way of doing this. As the Sprocs/Views need some knowledge of potentially more that one table. So simply reflecting on the View model properties would not be enough. I could auto generate a table for each view model, read this during development, then once the domain was stable and before we went to test convert these to views/sprocs?

So I guess what I am asking is:

1. Has anyone managed to solve the sproc/view auto generation problem I described above? (this would be my favourite outcome!) Or even better has designed a much more graceful solution!
2. Or is it more sensible to only implement raw ADO reads where they are absolutely necessary - i.e searches, and there dispense with the need for lots of sprocs/views. But then still separate out my queries into a separate channel (but inside some of them they use NHibernate, whilst others use my ADO reader).

(p.s I have looked at the other stackoverflow CQS related questions and I hope mine is different enough to warrant this question)

Answer 1

What do stored procedures solve for you? Why can't you use NHibernate for reads too? Are the queries NHibernate produces that bad?

If performance of reads is crucial for you, and the shape of your viewmodels is very different from how you store your model - making the denormalization process to a viewmodel too heavy to do on the fly, you might have to consider completely splitting reads and writes.

When you write something, you can raise an event - often done asynchronously - on which subscribers listening can store data on the readside in such a way that it's optimal for reads (close to the shape of your viewmodel). This would make querying really fast.

Since a picture says more than a thousand words..

You can read a good introduction to CQRS here.