CQRS read side ORM or pure ADO.NET?

Question

I'm implementing my first project using CQRS pattern, and now I have to decide how to implement read side. The first approach that I consider is to use ORM (Entity Framework/NHibernate or maybe someone can recommend me some faster ORM for this case ?) and map models to sql views. Initially I was thinking about using indexed views but I read article about some performance issue (during write) which induced me to abandon this idea (http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/06/02/be-ready-to-drop-your-indexed-view.aspx). The second approach I consider is to use pure ADO.NET (Data Read etc.) and write sql on my own. Which approach is best one in yours opinion? or maybe there is some better one?

Answer 1

I would recommend using dapperdotnet or ormlite.

I have used both tools extensively and find myself returning to them each time I move onto a legacy code to assist querying.

Both of them are very fast and provide just enough abstraction from raw ADO.NET to make your code readable.

Im not a huge fan of ORM's in general, I used to use them all them time but found that CQRS freed me up from using the same models to read and write so the ORM kinda became just a huge heavy pain in the butt.

Answer 2

It really depends on your system's requirements. Going with a lightweight object like Dapper, as @boz suggests, could very well work for your system. Also, if you're write side is fairly uncomplicated or you process commands to flatten out data, you could use a document repository like MongoDB or Raven (or a host of others) and then just have your read side pull objects out.

Again, it really depends on your requirements, but simpler choices like lightweight object mappers or NoSQL options could definitely work for you read side. Good luck!

Answer 3

Go with NHibernate+Fluent the best combo I've ever used. Clean approach and very easy to use.