I believe in the advantages of separating the query side开发者_如何学Python 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!
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?
精彩评论