[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.
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.
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
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.
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.
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.