A few days ago the P&P team delivered the new Data Access guide for highly scalable solutions. This is great. Few manufactures do this kind of stuff. My kudos to the team. if you still don’t have it feel free to check out this link: http://msdn.microsoft.com/en-us/library/dn271399.aspx . This post is for discussing the good and bad impression I got from that guide in no particular order.
- There is a nice classification of data base technologies which might be handy if you’re living a nightmare with all the DB products and technologies made available by different providers.
- There are really good (an in depth) explanations about indexes and partitions in you’re interested in the magic behind the scenes.
- I like the emphasis made in analyzing the query pattern as a big decision factor.
- Good descriptions and advice about the hash function used in key/value like storage.
Bad stuff (architectural point of view):
- The angular piece behind the proposed architecture for keeping the data access services synchronized is ONE Web Service Facade for routing the incoming request to the target data base. As such this operational web service is a main thing but there is no detail about how this guy will be scaled out. I see this like a single point of failure. The following image describes the service:
- Actually I’m having trouble to get this service into my head because there are several references in the guide conforming the service as a crosscutting concerns resolver. This goes against the whole Single Responsability principle.
- What’s the rational behind formating all the traffic between the web console and back end services with JSON?
- I really think Unity is not necessary here. This might be a typical case of dependency injection via unnecessary complexity. I mean, is it too probable the chance of dynamically changing the data base for this solution?
- I felt in front of an over used REST implementation. C’mon guys check the following controllers/operations:
- StatusController: Get
- SubCategoriesController: GetSubCategories
- ProductsController: Get, GetProducts
- ProductsCOntroller: GetRecommendation
- Is it only me or clearly the service methods are forced into REST verbs. This is a chatty interface indeed. These are code bloat controllers. Also there are multiple flaws in the API design. I mean, as an actor, should I consume ProductsController.Get or ProductsCOntroller.GetProducts?
- There are some wild ass definitions like “data-mapper pattern is a meta-pattern?. In someway, the Interpreter pattern is presented as a child of the data-mapper and I wonder why?. Why not the other way around? A typical egg and chicken situation.
- And finally and certainlly most important: what’re the reasons behind designing a “polyglot” data repository? Why non-use a 100% MS SQL Azure data access based solution?
Bad stuff (from my personal/subjective/human point of view):
- The scenario driven guides sound fine to me at the beginning, but I found I’m actually too lazy to read someone else’s specific/abstract situations (no offence, but I used to enjoy the Contoso‘ stories). Too much specific stories for me. Plus, I don’t really care about what happened in 1971 or 1990.
- Am I the only one who thinks shopping cart or movie rental kind of samples are much less than what an average brain can process? Again, I think Contoso did the job.
- A graph data base for a departmental organization? Are you kidding me? Unless your company employs millions of people I think is not a good example.
- Is there any need to describe a lot of non-relevant / domain specific functions?
- I’d prefer having no information about something rather than little/vague. This is the case for pricing. This is a big topic explained in most of the resources from the stratosphere or in a atomic level (no more “cloud cost” calculators with N input variables please!). I think something in-between is good enough.
Javier Andrés Cáceres AlvisMicrosoft Most Valuable Professional – MVP