ADO.NET Data Service in Plain English

I have been using ADO.NET Data Service in Silverlight since Astoria team released the client library for Silverlight. I didn’t have a particular idea to use that service except this is something new that I like to try. After reading a few article about Astoria, I come to know that I can retrieve the data from Astoria service by typing the URL in browser. And we have to use the different HTTP verbs for CRUD operations. That’s all? I think “No”. So, I raised a question in MSDN forum last week. Today, I got very useful and informative reply from Mike Flasko. (Thanks a lot for your reply, Mike.)

Here is the original thread that I posted in MSDN forum. Now, I’m here to share this information with you all. Hope that you will find it useful.

Question : What is ADO.NET Data Service (Astoria)?


Could anyone please explain me about ADO.NET Data Service in plain english without using marketing term?

– we can query the data by typing URL in browser.
– it supports CRUD operations with different HTTP verb.

But I believe that there might be some important reasons why people created this framework.

  • What is the ADO.NET Data Service?
  • What are the advantages of using ADO.NET Data Service?
  • What’s wrong with Web service?
  • What is the reason why making differnt HTTP verb for CRUD operation?

Thanks in advance.
Michael Sync

Answer from Mike Flasko (Astoria Program Manager [MSFT] )

Hi Michael,

In general the goals of ADO.NET Data Services are to create a simple REST-based framework for exposing data centric services. We built the framework in part from analysis of traditional websites and then looked at how architectures were changing with the move to AJAX and RIA based applications. One key observation the team had was that in traditional approaches to web development the information exchanged between a client (ex. a webbrowser) and the mid tier was a combination of presentation + behavior + data (ex. HTML file with javascript and inline HTML tables of data) and that the core interactions to retrieve raw data was between the mid-tier and backend store (ex. SQL server or other). When we looked at RIA, AJAX, smart client, etc applications it became apparent that these architectures pushed much more “smarts” to the client tier where the client first retrieves the presentation + behavior information (as a DLL in the case of a Silverlight application) and then as the user interacts with the client application, the app turns back (ex. background async call) to the mid-tier to retrieve the data needed to drive the user experience. This is nothing new (separation of presentation + behavior from data), but its interesting to note it now not only a best practice but mandated in the architectures of today’s web and RIA apps. From this we looked at how such clients could consume data from the mid-tier today and how could we help improve the experience for the developer. A few areas came up:

  • Creating and maintaining rich data oriented services with current approaches requires a significant developer investment
  • Building generation purpose client libs/tools with current approaches to data centric services is hard

For #1, imagine you wanted to expose the data in your CRM database to you client tier application. Further assume you want to enable typical application scenarios like retrieving sorted views of the data, paging over the data, filtering, etc. To expose this data as a set of callable remote methods (using current approaches to developing web services) you would need to write a large number of methods to expose each of the entities in your CRM DB (customers, orders, etc) and then add additional methods for each to retrieve entities by key, sort them, page over them, etc etc. ADO.NET Data Services, addresses this issue by allowing you to declaratively state the contract of such a data centric service, by telling us the schema of the data and having the data services technology automatically create the required remote endpoints, enabling paging, sorting, etc with no code from the developer. Then as you change your data model, your service endpoints also change.

For #2 above, an interesting artifact of a REST-based approach to web services is that it promotes creating a uniform interface. That is, how you address items in an ADO.NET Data Service (i.e. how to construct URIs), how to interact with data (using HTTP verbs), etc is the same across any ADO.NET Data Service, regardless of the data it exposes. This uniform interface enables code reuse against your web services such that one can create reusable client libraries and UI widgets for all their services. For example, the ADO.NET Data Service team is doing this by shipping .NET , Silver light, AJAX, etc libraries which can talk to any data service. In addition, this feature (uniform interface) enables us to add features such as LINQ to ADO.NET Data Services since the translation of LINQ query statements to URIs is stable and well known.

This is already probably a bit too long Smile, but in addition to the items noted above, additional advantages of REST-based approaches also apply such as rich integration with HTTP such that you can leverage existing HTTP infrastructure (ex. HTTP Proxies) deployed at large …

I hope that helps….
~ Mike

Here are a few links for those who don’t know about REST Service.  

Hope you find it useful.
Related ~

3 Replies to “ADO.NET Data Service in Plain English”

  1. Hi Mike!

    have a problem ..

    I have a c# app

    three tables

    ADO – used example in Silverlight 2 documentation .. word for word ..

    I load the three tables in order A, b, and c .. when I update C everything is cool .. when I update B it gives me an error saying The context is not currently tracking the entity.
    Parameter name: entity.

    If I change the order, loading a, c, and b with b being the most current, then I can update b .. but get a tracking error on c and a .. is there a way I can tell the system, through c# code, what is my “active” table when I update it, so I dont get the tracking error message?


    Frank Patton

Leave a Reply