Home > ADO.Net Data Services > Introduction to ADO.Net Data Services (Part 2: Reading and Manipulating results in the browser)

Introduction to ADO.Net Data Services (Part 2: Reading and Manipulating results in the browser)

My last blog was an Introduction to ADO.Net Data Services – Part 1: Creating a Data Service.  This blog will be an continuation of that blog, thus you need to create the data service from that blog in order to work with the things I am describing in this one.

ADO.Net Data Services can be “consumed” through HTTP Requests. Thus, we can use URI’s to read and manipulate data from ADO.Net Data Services.

  1. Make sure the ADO.Net Data Service from Part 1 of this blog is running – you can do this by hooking it up in your IIS or just debugging it from Visual Studio.
  2. When it is running you will see a webpage that should look similar to this:
    1. NOTE: as I stated in Part 1 of this blog there are a couple reasons the webpage might not look like this. The most common is your browser has RSS turned on. Turn off your RSS feeds to see the xml properly. The reason for this is because ADO.Net Data Services exposes the data in ATOM by default and the browser is interpreting that as RSS.
    2. What you are technically looking at here is xml that denotes all the collections in your object model. It has wrapped these objects in “collections” to show that there can be more than one entry for each. For example: The database had a table called “Employee”, thus the object model has a collections of Employees.
  3. capture.jpg
  4. So far all you have seen is the outer most collections of all the entities in the model. So, next we will show how to dig into some of the collections. We will do this with URI manipulation only.
      1. Note: my site is running under localhost:61823 so you will have to change that to whatever your site is running under. Also, I called my service DemoDataService, you will have to change that to whatever the name of the service is that you created in Part 1.
      2. What we have just done above is told the browser that we want to see the Product entity set of the data service. This is just like writing a query against the Product table in the database to return everything.
      3. capture8.jpg
      4. Notice that it has exposed all of the properties of the products. Plus it shows you all of the inner collections of the products through the “<link” nodes.
    1. As you can see above we can dig into the service deeper and deeper by knowing what to put in our URL. Also, you can figure out what to put in the URL just by looking at its structure and figuring it out. Below is a list of other commands you should try to see what is possible (Note: I am not showing all of the commands possible, just a few to show you the power of this technology):
      1. http://localhost:61823/DemoDataService.svc/Product(1) – This shows the product with the primary key of 1 or the product with an index of 1. This shows you how to get a single entity out of the entity set.
      2. http://localhost:61823/DemoDataService.svc/Product(1)/BillOfMaterials – This shows you how to get the BillOfMaterials entity set (collection) that is associated with product one. Notice, you can traverse down the entity tree just by using / and the next entity set. Also notice that if you go back to http://localhost:61823/DemoDataService.svc/Product(1) you will see that it has a line that says <link rel=”related” title=”BillOfMaterials” href=”Product(1)/BillOfMaterials” mce_href=”Product(1)/BillOfMaterials” type=”application/atom+xml;type=feed” />. This is showing you that Product(1) has an inner collection (as known as entity set) called BillOfMaterials. You know this because the “<link” stands for an inner collection (entity set).
      3. http://localhost:61823/DemoDataService.svc/Product(1)/ProductNumber – This shows a single property from Product 1.
      4. http://localhost:61823/DemoDataService.svc/Product?$filter=MakeFlag eq true – This will filter the Product entity set down based on all products that have the MakeFlag property set to true.
      5. http://localhost:61823/DemoDataService.svc/Product?$filter=MakeFlag eq true&$orderby=SellEndDate – This will order by the SellEndDate property. It also shows you that you can append multiple operations in your URL calls.
      6. http://localhost:61823/DemoDataService.svc/Product?$top=10 – This shows you how you can do paging in your entity set retrieves
      7. http://localhost:61823/DemoDataService.svc/Product?$expand=BillOfMaterials – This one is really interesting. The Data Service uses lazy loading (basically it doesn’t load up the inner entity sets unless asked to). So, this is how you can load up an inner entity set at the same time. In this example, we want it to actually load the data for the BillOfMaterials within each Product.

Now that you have seen some of the retrieval functionality, through URIs, that the ADO.Net Data Services has to offer, I am going to show you some of the other possibilites it has. To continue following along with this blog you will need Fiddler or an equivalent HTTP tool. Fiddler is a free Web Debugging tool and can be found at http://www.fiddlertool.com/fiddler/.

I am going to use Fiddler to show you how ADO.Net Data Services is just HTTP and how it responds to header information. The reason I am using Fiddler is to prove the point that ADO.Net DataServices interaction is pure HTTP request. There is nothing else going here like some other protocols such as SOAP. I am not saying this is a good or a bad thing, it is just important to understand the simplicity of ADO.Net DataServices in how they relate to the internet.

  1. Click on the RequestBuilder in Fiddler.
  2. Place your URL into the RequestBuilder and make sure it is set to GET. For this example I am going to place the URL in for the Product entity set: http://localhost:61823/DemoDataService.svc/Product
  3. capture1.jpg
  4. Hit the Execute button.
  5. After the excute has finished it will place a new row in the Web Sessions. Double Click on that row.
  6. capture2.jpg
  7. After the results have been returned, click on the Raw tab, this will show you the header information plus the content of the request.
  8. capture3.jpg
  9. Notice, in the header, the “Content-Type” is set to application/atom+xml. This is the default request content type for ADO.Net Data Services. However, this is easily changed by setting some request headers.
  10. Go back to the RequestBuilder in Fiddler.
  11. This time type in “Accept: application/json” into the request header section.
  12. capture4.jpg
  13. Now click Execute, double click on the web session that was just executed, and go back to the RAW view of the response.
  14. Notice that the Content-Type is now “application/json” and the response content is in json format.
  15. capture5.jpg
  16. JSON is a very power javascript object notation language. This makes it very easy to write javascript code and thus makes it really easy to right Rich Internet Applications that take advantage of things like AJAX.

So, what we just showed is that the client can actually tell the server how it wants to view the information just by setting some information in the Request Header of the http call. This is very powerful, because most services just present the content in one format. ADO.Net Data Services present the information in multiple formats and lets the client determine how it wants the information presented. Currently, ADO.Net Data Services supports ATOM (XML) and JSON. It is reported that Microsoft is working on supporting a more generic XML format also (but it is not out in the extension package as of now).

It is important to note that I only showed a “GET” command here – which does a retrieve. This is because that has the most complexity in setting up the URL commands. However, you can update, delete, and add through the ADO.Net DataServices also. To do this you use regular request processes:
GET – Retrieve
POST – Create
PUT – Update
DELETE – Delete

This is the second part of this blog series. The last part will be Part 3 –  Reading and Manipulating ADO.Net Data Services results in a .Net consumer application. In this last part I am going to show how to use .net as the client application (in contrast to this blog where I showed how to use a browser as the client application). However, it is important to note, that everything I did in this blog was through standard HTTP and header calls. So, any web application can use these techniques to call out to a Data Service. But, like any good .Net application, they made it really easy to work with these in the .Net client apps (WPF, Winforms, Web Applications, etc…). So, my last post will show how to easily work with this stuff in a .Net client application.

Categories: ADO.Net Data Services

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: