LINQ to REST - A much better name for Astoria

Basically here's the flow of what he's talking about:

1. Define your data source. This is most commonly going to be an Entity Framework source such as a SQL Server or Oracle database. But remember, from my previous blog post, you can use any queryable data source with a little effort. This is huge, huge, huge. Did I mention it was huge?
2. Once you've got your data source (either an EF or your own queryable object model) create an ADO.NET Data Service using VS 2008.
3. What you get is a data service with a code-behind file that has a parameter missing from its generic definition. That parameter should be the name of the queryable data source that is being exposed by the ADO.NET Data Service.
4. Once you've got your data service defined, build it and hit the service a couple of times. The ADO.NET RESTful URL query syntax can be found here. This is a word doc that contains the usage patterns for Astoria, so you can download it right from the link in this post.

5. Once you're sure that it's working and that it's serving up data properly, and you've tested both read and write scenarios (remember that with this CTP all entities start out as hidden, so you need to write code to expose them, as shown below)
   
   public static void InitializeService(IWebDataServiceConfiguration config)
   {
       config.SetResourceContainerAccessRule("*", ResourceContainerRights.All);
   }

6. Now you're going to want to create a client library. While you can access ADO.NET Data Services directly using your favorite XML over HTTP tool, or even your favorite ATOM/APP client library - it's much easier if you know you're going to be consuming the service from a .NET client - ADO.NET Data Services come with their own client library.
   1. The first step in creating the client is generating the local models. Keep in mind that this is not remoting, there is no back-and-forth marshalling. You're sending messages over XML and receiving data over XML, and those payloads have C# object counterparts. To generate the local model, you use the webDataGen.exe application (at least in this CTP). Here's a sample of its invocation: (you can find this file in %ProgramFiles%\Microsoft ASP.NET 3.5 Extensions)
      webdatagen /uri:http://localhost:12345/MyData.svc
            /mode:ClientClassGeneration /language:CSharp /outobjectLibrary:ClientLibrary.cs
   2. Now just add that CS file to your client project and add a reference to Microsoft.Data.WebClient
7. Your client can now consume the data exposed by the ADO.NET Data Service. The payload format is now completely irrelevant to the smart client (though you'll want to use JSON when consuming the service from Ajax). You can now write queries that look like this:
   
   var accountsList = from account in entityClient.Accounts orderby account.Name select account;
   
8. Enjoy!

I'm working on a bunch more samples, but I agree with Andy Conrad here - using LINQ to consume the ADO.NET Data Services client library which is hitting an ADO.NET Data Service in the back-end, exposing either an EF model or a custom queryable object model. For people like me, this triggers the pleasure center of my brain directly.

I'll leave you with one more thought... what are you going to want to use as your data source for your MVC application? An entity model that is jammed directly into your web application, or, what if instead you consumed the ADO.NET Data Service client library and wrote "LINQ to REST" queries against a loosely coupled back-end data source?

p.s. I know you're thinking "What happens if the entity model changes for the back-end service?". With this CTP, you now have the ability to refresh the entity model from the database schema. Re-run the webdatagen command line tool to rebuild the client library, and then you just need to tweak your client code to have the new property names, etc.

tags: astoria  dataservices  rest  linq  

links: digg this    del.icio.us    technorati    reddit