The Register ®

Biting the hand that feeds IT

The Register » Software » Applications »

Original URL: http://www.theregister.co.uk/2007/11/13/project_astoria/

Project Astoria a hit at TechEd

By Tim Anderson
Published Tuesday 13th November 2007 14:45 GMT

There was a buzz last week at TechEd about Project Astoria (http://astoria.mslivelabs.com/Default.aspx). The reason is that it promises to simplify development of web applications that deal with data - which is most of them. Astoria is a REST API for ADO.NET, and hooks into the new Entity Framework object-relational mapping layer. Therefore, it solves two problems in one go.

Here's a quick look at how it works. Let's assume you have a database which stores some information you want to present in your web application. Step one is to use Visual Studio to generate an Entity Data Model from your database.

Next, you tweak the model so it looks as close as possible to the objects you are storing. The framework should deal with the complexities of mapping collections to linked tables and so on.

Now you create a new ADO.NET Data Service (sadly, this may well be the official name for Astoria), and point the service at your model. By default a new service does not expose any data, for security reasons, but by writing an InitializeService method you can configure which objects you want to publish.

Run the service, and the objects in your model are now URL-addressable. It's pretty flexible. For example:

[serviceurl]/Products : return all the products (yes, you can do paging).

[serviceurl]/Products[2]: return the product with an ID of 2.

[serviceurl]/Products[Color eq 'Blue']: return all the blue products.

[serviceurl]/Customers[2]/Orders/:return all the orders for the customer with an ID of 2.

The data comes back in either ATOM or JSON format. Naturally, each element in the returned data includes its URL. Let's say you have an AJAX application so you are calling this service from JavaScript. Iterating through the results and populating an HTML list or table is easy, especially as Astoria includes a client JavaScript library. There is also a client library for .NET applications. You can also add or update data with HTTP PUT, or remove it with DELETE.

You can extend your Astoria API by adding arbitrary methods that have the [WebGet] (or presumably [WebPut] or [WebDelete]) attribute. You can also add "interceptors" - code that gets called just before requests are executed, to enable validation or custom security.

Presuming it works as advertised, Astoria is a more natural and concise way to handle data than SOAP web services, and easier than devising your own techniques. It should work well with other technologies such as Adobe's Flex. It will play nicely with mash-ups, since many other services out there use ATOM or JSON. It is a natural fit with AJAX and will work well with Silverlight - see here (http://www.silverlightdata.com) (Silverlight 1.1 Alpha required) for an example.

Astoria will not be finished in time for the initial release of Visual Studio 2008, though reading between the lines it might be done in time for SQL Server 2008. It will work with any database server for which there is an Entity Framework provider. I was assured that creating such a provider is relatively easy, if you already have an ADO.NET 2.0 provider, so it is reasonable to expect wide support.

I think this will be popular.

This article originally appeared in ITWriting (http://www.itwriting.com/blog/?p=393).

Copyright (c) 2007, ITWriting (http://www.itwriting.com/).

A freelance journalist since 1992, Tim Anderson specialises in programming and internet development topics. He has columns in Personal Computer World and IT Week, and also contributes regularly to The Register. He writes from time to time for other periodicals including Developer Network Journal Online, and Hardcopy.

© Copyright 2008