ADO.NET Data Services Projections Makes Sliced Bread Jealous

The other day I ran into a blog entry from the Astoria team discussing the projections feature of the 1.5 CTP2 version of the product. If you're not familiar with ADO.NET Data Services (formerly codenamed Astoria), it's basically a layer that you can put on top of an Entity Data Model and it will expose that model as a RESTful service. The URL format for this RESTful service is quite flexible, allowing you to select individual rows, perform filters, sorts, and many other things.

One of the new things that you can now do server-side via the new CTP2 URL syntax is projections. Projections actually allow you to control the shape of the output coming back. You can specifically choose which properties on the entity you want. Even more awesome is that this can be controller hierarchically. So if you bring back an Order entity and you include all of the OrderItem entities for that order, you can tell the server that you only want the customer for the Order and you only want Quantity and Price for the order items.

To perform a projection on the URL, you just use the $select parameter, like this:

blah.svc/Orders?$select=OrderID,Quantity,Price

And to control the shape of hierarchical data:

blah.svc/Orders?$select=OrderID,Quantity,OrderItems/Price,OrderItems/Quantity&$expand=OrderItems

At this point when I saw this I started having convulsions of pure joy. The main reasons being that every ADO.NET Data Services URL query will output either AtomPub or JSON. This means I can get only the columns I need and give them to my Ajax calls. Then I noticed that support for the new projections is actually in the Astoria client library as well, allowing me to write the following query:

var q = from order in ctx.Orders
        where order.Price > 300
        orderby order.Price descending
        select new { Price = order.Price, Quantity = order.Quantity };

This will translate into an Astoria query that filters, sorts, AND projects all on the server side, leaving me with a network footprint that only transmits the information I want and nothing else. This is a godsend if you have entities with huge amounts of columns but each individual query might only need to use 1 or 2 of those columns at a time.

And now, if this wasn't ridiculous enough, you can actually perform updates using the projected objects, AND those updates will ONLY transmit the information necessary. For example, if I only want to change an order's price and I got the price from a projection, I don't need to carry the entire order payload across the wire in order to commit the change:

order = q.First();
order.Quantity = order.Quantity + 42;
svc.UpdateObject(order);
svc.SaveChanges();

This will figure out that the only thing changing is the Quantity field and it will ONLY send that information. After discovering the combination of projections and the efficient round-trips of Astoria, this is when my head exploded.

If you have a multi-tier scenario and you're using an Entity Data Model (EDM), then you should definitely look into using ADO.NET Data Services to expose that model via services because now with projections, you can really do some unbelievable stuff. All that garbage code you used to have to generate to convert between DTOs and ViewModels and Entities and back again? You can delete ALL of that crap.

I've said it before but the folks working on ADO.NET Data Services deserve a medal. If you see a member of that team, buy them a beer. You have no idea how ridiculously complicated and difficult it is to write code that supports arbitrary projections like this. I'm pretty sure every time you run an Astoria query with projections, an Angel gets its wings.

tags: astoria  adonet  dataservices  data  entityframework  projections  

links: digg this    del.icio.us    technorati    reddit