0

I believe in the advantages of separating the query side from the command side. For the query side, we can provide the needed information in the most optimized form for the client; which makes it fast and easy. In my case, I use a very simple implementation of the query side, which basically means I want to to use the same database as the one used for the command side.

My question is about how I can implement the query side, and this is what I was thinking:

1/ My first thought was to use a WCF data service, based on an entity framework model that is generated on database views. I would then create specific views for specific UI's. One view can then merge data from various tables. But this seems very limited, because you can't pass parameters to views, and for most queries I need to pass parameters of course.

2/ A WCF data service, based on an entity framework model that is generated on database tables. But then, the query model would be the same as the one used for the command side. And you don't get back the information in the way that is best suitable for the specific UI.

3/ A WCF data service, based on an entity framework model that is generated on database stored procedures. But then there's extra work to expose them; and calling them is also a bit strange (magic strings).

In order to help me to make a decision, I would love to hear your comments to see what would be the best way of exposing my query side. Thanks!

L-Four
  • 13,345
  • 9
  • 65
  • 109
  • @Will. Why would this be closed? It's a specific question about a facet of a specific architecture. There was no request for info on the benefits of the architecture or even a vague request for a how-to guide. The OP did their investigation and asked for advice on the best choice for a specific problem (from options provided by the OP no less). Closing this seems very heavy handed. – JRoughan Sep 19 '11 at 15:42
  • @JRoughan: It does seem heavy handed, I'll grant you. Lud is more than free to edit and flag for reopening, if he can respond to the points in the close reason. Note, in your defense, you point out he's asking for the "best choice", which is one of the things we try and keep to a minimum--subjectivity. Also, he appears to be asking for an open-ended discussion about the subject-"I would love to hear your comments." I'm not saying that the question isn't without merit, it is just not the kind of question we encourage here. Also, [meta]. –  Sep 19 '11 at 16:16
  • @Will: Fair call, it just seemed head and shoulders above what is usually closed for those reasons. Point taken about encouraging the greater good, though. – JRoughan Sep 19 '11 at 16:37

1 Answers1

1

I'd go with option 1. Create fully de-normalised views for the specific queries your application will be making.

When you say you can't pass parameters to views what do you mean? Why can't you run a regular query against the views?

JRoughan
  • 1,635
  • 12
  • 32
  • 1
    Oops, I feel stupid now! So you can use these views just the same way as you would use tables then, and query on them? Indeed, then I can use my preferred option. Thanks!!! – L-Four Sep 19 '11 at 10:55
  • Note that a benefit of CQRS, apart from the design philosophy, is the performance gains of separating out your reporting/query db from the operational/command side. If these are on the same DB you would probably want to find a way of throttling the query side to prevent impacting the command side. – JRoughan Sep 19 '11 at 11:17
  • Meanwhile I tried it and indeed, I can query the views as I want to. Concerning your remark: the goal is to keep it simple for now (low traffic), but once it is needed, I can easily split the database because everything is ready for it. Thanks again for the insight :) – L-Four Sep 19 '11 at 11:47