First session of the day was Anders Hejlsberg on LINQ to SQL. As the conference has proceeded my interest in LINQ has increased and this session was the culmination of that. LINQ to SQL is basically an OR mapper and a very impressive one at that. As I wrote in my post regarding the LINQ project in general you get the ability to do integrated queries in the .NET languages.
What LINQ to SQL provides you with is the following:
You'll derive from this class in order to create a strongly typed representation of your own database. This effectively becomes the manager for your database for stuff object references and primary keys. More on this later.
For each table you get a class representing that table. You can choose a number of ways to attack the mapping of tables to objects. You can either use the visual designer in Visual Studio to drag and drop tables from your SQL Server datasource onto the design surface this creates the actual code for the class, you can go class-first where you create your classes first and then map to your datastore either by adding attributes to the the members of the class or you can externalize the mapping in a XML file, finally you can opt for the full blown mapping provided by a tool called SQLMetal which connects to your datastore and creates classes for every single table in there.
Of course relationships are observed and properties are created to map those as well. For example you have the classic customer and orders mapping where a customer has many orders. The orders would be translated into a collection available on the customer class. Very nice indeed.
This wouldn't be LINQ if you weren't able to query your data. LINQ provides are very rich model for querying data be it SQL, XML, objects, DataSets, and more. You can do all kinds of crazy stuff not available in SQL, e.g. you can use the output of a stored procedure to further query that data. It's all handled by LINQ which does some additional manipulation in memory. Ad hoc joins are available like you would expect. Finally LINQ uses a notion of deferred execution for executing the queries. What this basically means is that the query won't get executed until you actually need the output. So defining the query doesn't execute it, it won't get execute until you actually use the results it produces.
Of course the language constructs you use to create your queries are the same regardless of the data your are querying so you only need to learn a single set of operations in order to work with all the supported data stores.
For updating and inserting data LINQ provides a mechanism for keeping track of the changes. You can go nuts and do a whole bunch of updates and nothing gets updated until you call the SubmitChanges() method. Pretty nice to be able to batches in this manner.
Procs are supported by creating methods representing each stored procedure on the DataContext class. Each method returns a strongly typed resultset which contains the output of the proc. Say for example that you do a proc which returns CustomerName and CustomerAddress, your result would then have properties with the same names. No more looking at a method which returns a DataSet, then having to go to the database, and look at the output of the stored procedure in order to figure out which columns you have to work with.
I was very curious as to how LINQ to SQL goes about getting data across and I've very pleased to report that all my concerns were put to shame. For example I was wondering whether data projection would yield lots and lots of different anonymous types flying all over the place thus lessening the value of our business objects. This turns out not to be a problem as LINQ to SQL is strongly typed which ensures that you only get your business objects returned. Also we use lots and lots of lazy loading to allow our web apps to scale well. This fortunately is also supported in LINQ, it's the default behavior in fact, but you can override it if you want. You can be very explicit about what you want LINQ to bring back to you.
If you haven't picked up on it yet I can tell you that I' very excited about LINQ at this point. Now all I need is for someone to create Query Analyser for LINQ for me and I'm good to good. What's even more interesting about such a tool is the fact that you would be able to target not just SQL but all the supported data store, although the queries wouldn't be interchangeable.
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.