Microsoft is working on a project called Astoria. It consists partly of a new technology acompanied with a library and partly of a free service. It's a data service that is reachable over regular HTTP requests and standard HTTP verbs such as GET, POST, PUT and DELETE. The data is formatted as plain XML, JSON or RDF (experimental). The service that is acompanied is a hosting service for this data service. You will get a 100 MB data service hosting for free. The Astoria runtime library makes use of the ADO.NET Entity Framework part of Visual Studio 2008 and .NET 3.5 and is built on top of Windows Communication Foundation. I'm very interested in this new technology. I might try it sometime in the future. But we have to remember this service is experimental. It might even cease to exist some day.

• Project Astoria Team Blog
• Astoria Online Service
• Astoria Online Service - Getting Started
• Sample Northwind Astoria Service - Customers in London Query
• Astoria Documentation

LINQ is one of the new feature we will get in .NET 3.5. I think it's a very interesting new technology that consist of LINQ the language, and some elements that make use of LINQ for use with XML files or databases. LINQ to SQL is one of the techniques to use LINQ to communicate with the database. There are a few other techniques that use LINQ in combination with the database: LINQ to Entities, LINQ to Dataset. I started with the 5 part LINQ to SQL series by Scott Guthrie:

1. Using LINQ to SQL
2. Defining our Data Model classes
3. Querying our Database
4. Updating our Database
5. Binding UI using ASP:LinqDataSource control

I'm at a new customer and I want to introduce an ORM tool. I've talked to the Database Administrators, and learned their requirements. All querying (Insert, Update, Delete and Select) need to be done using Stored Procedures.

I wasn't happy with this requirement because I was already thinking about using NHibernate as an ORM tool. A few months ago version 1.2 from NHibernate was released, with support for Stored Procedures.

I was reading the documentation (chapter 13.3) about the use of custom SQL / Stored Procedures for create, update and delete. I am not really worried about those queries, just write once, and use with the objects for mapping.

But about the selects, I'm worried. After reading the documentation about the usage of Stored Procedures for querying (chapter 13.2.2), I'm still not convinced about using Stored Procedures for selects. It supports mapping the results to objects, very nice. But what about a dynamic where-clause? A where-clause that makes use of joined tables for its filtering?

After this, I am just guessing, lazy loading won't work with Stored Procedures either, will it?