What dataccess technology is best suited for CQRS query Webservices?

What tools are people using for querying their Read database and populating DTO's?

We currently have our R开发者_StackOverflow中文版ead model in a Sql2008 database and perform all our queries through a WCF service, We're using Fluent NHibernate to populate the data contracts using auto-mapping, but maybe this is just overkill?

Our requirements are really this...

1. No Sql code in the Webservice
2. No mapping code in the Webservice, we ideally want to map by conventions, the Read database fields have the same names as our Data contract properties. We don't want to write and maintain mapping code by hand.
3. Minimal resource usage on the webserver.

---

IMHO Overkill.

I'm using just a flat file system with JSON/ProtoBuf serialization. Web services are dead simple and schema can be anything. The stack easily moves to the cloud (using Azure Storage Blobs) for almost-infinite scalability as needed.

Details: http://abdullin.com/journal/2011/1/19/scalable-and-simple-cqrs-views-in-the-cloud.html

---

I have used WCF Data Services with a lot of success on the read side. I have written a blog post about it. Check it out at http://blog.fossmo.net/post/WCF-Data-Services-A-perfect-fit-for-our-CQRS-implementation.aspx

---

I used ADO.NET core with stored procedures in the database. Then using a tool I've written, all of the data access code is generated using the result of each stored procedure as the structure of Dtos.

The tool with source code is available on my blog Data Access Layer CodeGen

Now since you're simply returning the data via a WCF service, then there is no need to go from DataReader, to Dto and then serialize the DTO. In other words, you're iterating over your resultset 3 times in the process of sending the data out. So if you want to reduce the resource utilization on your server and get better performance then you can use the "DataReader-Wrapper" classes that the tool generates (along with the Data access code).

The DataReader wrapper classes are like strongly typed DataReaders. I have another post where I talk about these and their benefits DataReader Wrappers - TypeSafe

Of course, you could modify the tool (since you have the source code as well) to generate all of your code including the WCF service. So all you really have to do is write a stored procedure and you're done. All of the DataAccess code (using ADO.NET Core - so it's lightweight and super fast), business layer code and WCF code is really just "busy work" if you get what I mean.

EDIT Reason for using stored procedures

1. A stored procedure can returns multiple result sets in one call.
2. A stored procedure can accept parameters.
3. A stored procedure can have control flow statements and can call other stored procedures (so you get procedure re-use kind of like refectoring a method such that you can call it from multiple other methods).
4. It is far easier to optimize a stored procedure since the tools work really well with them