query/reporting layer design question (DDD/CQRS)

i'm thinking about how i would like to structure my query/read layer for my application and i think what i am going to do is create database views to flatten out the model and use entity framework for my data access.

my question is, should i just allow my controllers direct access to my IQueryContext, which is just essentially abstracting the EF context. or should i create a transaction script style query service, like ICustomerQueries that contains all the related reporting methods? or maybe each query is its own concept and lives in its own object ie; GetProductsByCustome开发者_运维百科rQuery

any help/ideas/arguments would be great!

I'd keep the query side as simple as possible. I'll probably get flamed for this, but in my opinion getting as close to raw SQL as you can, in some cases even down to SELECT * FROM ..., might suffice.

Thus: Expose your flattened out views -- and later your denormalized tables -- via EF or Linq2SQL, and bind them to your UI (I'd even go as far and question the need of an ORM at this point). No further abstraction layers required. Saves time to focus on the Core Domain.

I tend to use WCF Data Services on the query side. So, I have an Entity Framework model of the Read database, then create a WCF Data Service on top of that (that only takes a few minutes), then query that WCF Data Service.

It's easy, it's consistent, you can configure it for read-only access, it supports LINQ and even the OData protocol, so that you can write queries in your URL.

See also:

• OData: http://www.odata.org/
• WCF Data Services: http://msdn.microsoft.com/en-us/data/bb931106