Talking Points: ADO.NET Data Services

  • Article

[CORRECTION ADO.NET *NOT* ASP.NET DATA SERVICES] – DON’T WRITE BLOGS AFTER 7-HOURS DRIVE]

Customers demand for richer experience on the web has created the requirement for data access at the point of need – the client. With the traditional post-back model of ASP.NET this is simply not possible with the agility required by the new application models. So client apps AJAX, Silverlight or Adobe Flash must rely on a set of conventions to be able to access and operate on data locally, while the data source itself must remain client independent so that it can be reused in different scenarios.

ADO.NET Data Services  facilitates the creation of flexible services that more naturally integrate data to the web. It relies on semantic over data via an Entity Data Model and it surfaces those data services as REST-style resources over an addressable URI. So interaction can occur over simple HTTP (GET, SET, DELETE).

Data Services can enable AJAX Applications, Silverlight Applications, Online Services, and Mashups.

Scenarios:

  • If you develop an AJAX Application, the client requests a page and the server returns HTML and JavaScript. At that point all communication happens between the client (JavaScript) and the server. This situation will typically call for a set of services on the server that the client can call using AJAX. In this scenario, the service required for client-server communication is largely data centric.
  • In a Silverlight Application, the server returns the compiled Silverlight app, which then runs on the client’s machine. At that point any client-server communication is done with services. A lot of the services required by the client might be data-centric, at which point we’re in the same situation.
  • If you’re creating an Online Service that is meant to provide data over the cloud, then you’re creating nothing but data access logic, so we’re looking at the same scenario as before.
  • Finally, if you’re creating a Mashup, your server returns the UI of the mashup itself, which in turn contains logic for communicating with the data feeds that you’re mashing up.

There are many other scenarios that require the use of services, but these exemplify enough the need for services that are largely data-centric. Keep in mind, that there are plenty of scenarios where service functionality that is operational in nature and not data-centric, is also typically required. But in many cases in these scenarios, the common need is data.

Data Services Tenets

We see the need now for a service that is purely data-centric. Something that could easily accommodate all of the mentioned scenarios and alleviate the boilerplate work.

  • The tenets for such a service are:
    • That it provides full CRUD functionality. We need to be able to Create, Read, Update, and Delete data from the service, as this is a very common need.
    • That it offers paging functionality, as well as sorting and filtering.
    • The service should also be RESTful, where every resource has its own URI, as well as provides a standard protocol for publishing data to it.
    • Finally, the service should be extensible, to allow additional logic to be built on top of the foundation of the data service.
  • ADO.NET  Data Services fulfill these tenets. A Data Service is itself a WCF service, so you get a lot of functionality and behavior from that that foundation.
      • Data Services provide rich functionality for Entity Data Models, allowing you to re-use an EDM you already created.
      • In addition, you can use a custom CLR model that exposes its resources through IQueryable collections.
      • This can either be a LINQ To SQL model, or your own custom model. Data Services see the two as the same.
  • Because the data service sits on top of your object model, it can expose your data automatically for you (if you tell it to), and provide full CRUD on that data, completely out of the box.

Addressing

These are some typical data service URIs. Notice that the service itself is a file with the “svc” extension.

RESOURCE URI
Service AdventureWorks.svc
Entity Set AdventureWorks.svc/Customers
Entity AdventureWorks.svc/Customers(1)
Relationship AdventureWorks.svc/Customers(1)/Address
Property AdventureWorks.svc/Customers(1)/Address/City
Property AdventureWorks.svc/Customers(1)/FirstName

There are also two pseudo-members that can be added to your URI request. $metadata to retrieve CSDL metadata for the data service. This is the WSDL equivalent to data services. It can be used by clients to determine how to create a proxy. $value allows you to retrieve a scalar property without any formatting applied to it. The $value modifier is append directly after a scalar property in the request URI.

$metadata AdventureWorks.svc/$metadata
$value AdventureWorks.svc/Customers(1)/FirstName/$Value

Query Options

  • Query options are special URL parameters that can be appended a request URI.
  • All query options are prefixed with a dollar-sign:
  • To order a data request, you can use the $orderby query option, which allows you to specify a comma-separated list of properties to order by, along with the sort direction. The default sort direction is ascending. The sort columns can even be properties that are embedded within entity nested types and relationships.
  • In order to provide paging, data services provides the $skip and $top query options. These simply take an integer value of the number of records to skip and the number of records to receive. The two aren’t mutually exclusive. If you don’t also specify an $orderby option, the requested entity’s keys will be used to sort the data before it is paged.

Clients

  • Because data services have a RESTful interface, you could program against them using any HTTP stack, such as the HttpWebRequest class in .NET.
  • HttpWebRequest doesn’t offer the rich data platform client functionality that developers might expect, which is why ADO.NET Data Services provides a set of client APIs for working with data services in a more intuitive way:
    • There is a client API for .NET applications as well as Silverlight applications. These allow you to consume a data service from within managed code.
    • There is a new data source control that allows the consumption of a data service using the familiar data source paradigm with an ASP.NET application, that can be easily connected to a GridView, ListView, FormView, or DetailsView.
    • Finally, there is a client-side API that allows data service consumption using the ASP.NET AJAX library.
  • With these client options, you are able to consume a data service from within any .NET application, regardless of the environment.

Summary

Rather than inventing yet another access framework for web data, ADO.NET Data Services leverage our existing data access model and exposes it using already familiar mechanisms like URI and HTTP GET/SET etc. Yet, it enables very powerful new scenarios where an application can have full CRUD capabilities exposed to the user without the need for developers to re-invent the wheels each time. Data Services enable common scenarios that require rich RESTful data-centric services with full paging, sorting, and filtering right out of the box.

References

Feel free to watch this interview with Saaid Kahn, Program Manager in the VS team. He shows a quick demo of ADO.NET Data Services in action. Also, a couple of quick vids from asp.net site showing Data Services/AJAX and an Entity Designer video.

Joel Reyes

Technorati Tags: ADO.NET Dynamic Data