ADO.NET Data Services Part - II

In part – I of this series, we saw how we can perform GET operations over the web with ADO.NET Data Services. But any data model should also allow inserts, updates and deletes. In ADO.NET Data Services, you can do that by using the appropriate HTTP header and passing the corresponding values.

 

Data Manipulation

 

For eg. A simple insert with ADO.NET Data Services will look like below

 

            NorthwindEntities test = new NorthwindEntities(new Uri("http://localhost:6129/NorthwindDataService.svc"));

            Suppliers addSupp = new Suppliers();

            addSupp.CompanyName = "test supplier add from web client";

            test.AddToSuppliers(addSupp);

            test.SaveChanges();

 

This in-turn sends a HTTP POST Request with the Supplier Name enclosed in the given format. In this case, the ATOM XML will look something like

 

 

 

 

 

 

ATOM:

<entry  xmlns:ads="http://schemas.microsoft.com/ado/2007/08/dataweb"   

        xmlns="http://www.w3.org/2005/Atom">

  <content type="application/xml">

    <ads:SupplierName> test supplier add from web client </ads:SupplierName>

  </content>

</entry>

 

You can similarly do Update and Delete Operations. For update, the HTTP header you would use is HTTP PUT and for Delete, it would be HTTP DELETE. You will hardly have to code the HTTP Headers yourself but it is always good to know.

 

Advantages of ADO.NET Data Services

 

There could be a lot of places where you could be thinking about using ADO.NET Data Services. There are a few that come to my mind right away

 

1.       Support for AJAX based frameworks

 

Use of the JSON format makes it much easier for silverlight based applications to get and manipulate records. Before ADO.NET Data Services, SILVERLIGHT applications had to use AJAX to manipulate the records. This way building RIA becomes a lot easier.

 

2.       Enables use of HTTP Caching infrastructure

 

Since ADO.NET uses REST it can use HTTP Caching infrastructure to make sure a lot of data is cached. Compare this with traditional services which are predominantly stateless. This way there is potential to reduce a lot of network traffic.

 

3.       Underlying Data Source is completely encapsulated

 

With ADO.NET Data Services in place, you can build your Data Access Layer which is independent of the underlying data storage technology. Suddenly you are not bothered about pooling connections, using the right providers. All you are worried about is whether you have access to the URI.

 

4.       Separate Control Operations from queries\stored procedures

 

Let me take an example. Suppose you wanted to write a stored procedure that gives you the list of the contacts in your application. Your user interface has a sort feature. To implement sort, you have two options viz. a) Get the data in a dataset and sort the records of the dataset or b) write two stored procedures that do sorting asc or desc. Now imagine this is the ADO.NET Data Services world. To sort or filter your records you don’t need to change your stored procedure all you need to change is the URl. That does make things simple isn’t it?

 

That’s it for now. In Part –III we will actually be creating ADO.NET Data Services and using that from a client that we will build. So back in a week with the next part.