Connected, Disconnected and DLinq

Here is another FAQ question that has come up at PDC.

Since DLinq is a part of the next version of ADO.NET, it is natural to ask - is it connected or disconnected? After all, we have talked about connected vs disconnected components in ADO.NET quite a bit. DataReader is connected (you are using the underlying connection while consuming the data) while DataSet is disconnected. You need to use DataAdapter to bridge the two worlds. All nice and explicit.

Quite often you need to combine the two modes (as developers do with the DataAdapter + DataSet combo). Wouldn't it be nice if the data access library knew how to provide the benefits of disconnected mode while connecting as and when needed? You would not have the old ADO problems of scalability that ADO.NET solved and yet you would not have to wire all the components explicitly and do all the plumbing yourself. Well DLinq does exactly that. Here is my demo example decorated with comments

class Driver
{

static void Main(string[] args)
{

Northwind db =
new Northwind(@"c:\Northwind\Northwnd.mdf");

db.Log = Console.Out;

int x =3;

var query = from p in db.Products
where p.SupplierID == x
orderby p.UnitsInStock
select p;

// No SQL execution up to this point.
// The following line will cause a SqlConnection.Open() and SQL query executtion
Product sauce = query.First();

sauce.UnitsInStock += 10;

// No SQL execution up to this point. Connection resource is not used.
// The following line will cause SqlConnection to be opened again & a SQL update command execution
db.SubmitChanges();

}
}

 The use of connections and SQL command execution is essentially driven by the deferred execution (or lazy eval for the functional language folks) in LINQ.