ADO Data Services (Astoria), does it fit well in the Enterprise? RRS feed

  • Question

  • I've been trying to get my head around ADO Data Services and although I can see it is very compelling way to get/set raw data directly from a UI based client I'm uncertain how it should work in the Enterprise. If we ignore the end-user client for the moment and consider the business tier then I could see that in SOA you've got a nice abstraction based upon a very simple URI format. Ok, so we've got a number of choices about how we provide that abstraction but this is compelling because it's platform/language independent. Now if we bring the client back into the picture then I start to get a little confused. The majority of the examples are all about speed of development, "look how fast you can CRUD your data, drop this and wow off we go". Now this is nothing new, it's taken an age for binding to start talking to objects rather than data tables so I shouldn't expect the examples to change, however I'm not sure what the story is with ADO.DS. E.g. If I used MVC would the I call the business services using AD.DS which in turns interacts with the data stores with another AD.DS? Or is AD.DS only really for use with the data stores?  So would the stack look something like, MVC (Pres)->WCF (to Biz)-> AD.DS (to data). What's nice about using WCF rather than AD.DS is you can postpone (or change) the transport mechanism whereas I believe you're stuck with some form of string with AD.DS which maybe a performance hit.

    What are your thoughts, do you intended to jump on the AD.DS bandwagon?

    Thursday, June 12, 2008 6:05 AM

All replies

  • I am not fully immersing myself into Astoria yet or my apps.


    You are correct that it will be used in Orchestration(BL), not directly to UI.


    I would use it to load static data for a cache object (like list of states, cities in US), something very straight forward simple SQLs.  But again, LinQ to SQL may do the same probably with added flexibility.


    May be it is not for people like me.  It is probably for people like a program leader in my organization that was a strong VB/COM/SQL Server but never got upgraded to .NET.  So he is used to two tier application development.  He has all the business logic buried in stored procs not in VB.  When he migrates that code to .NET, it may make it easier for him to expose the SQL Server stored procs as ADO .NET DS and use them in Windows Forms presentation layer and still call it as SOA app because now he has http/wsdl based service end point to his application...


    Interesting discussion Pkr.  Lets see what others think


    Friday, June 13, 2008 12:33 AM