LINQ to SQL

Over the past couple of months I have had the opportunity to build some small "utility" type of applications using Microsoft Visual Studio 2008 and the .NET Framework 3.5. In these utilities I had a lot of freedom since they were "one-off" type projects that were not going to be put into production use. I took advantage of using LINQ to SQL for the database portions. I must say that I am extremely impressed. Although support is pretty much limited to SQL Server I thought it made my database access much easier than any O/RM that I have ever used. I wanted to make a quick list of things that impressed me about LINQ to SQL:

1. The ability to use drag and drop functionaliy from the server explorer right onto the canvas and the automatic drawing of relationships between tables. The relationships carry right over into the code and foreign keys can be exploited so that LINQ queries can easily join the data. For instance, if you have a CUSTOMERS table and a related CUSTOMER_STATUS table with the following layout:
   
   You can then you can easily query all the customers with a "Good" status but issuing the following query:
   
   
   var GoodCustomersQuery = (from c in m_DbContext.CUSTOMER
   where c.CUSTOMER_STATUS.Status = "Good"
   select c);
   
   This should encourage developers to properly use foreign keys (finger pointed right back at myself too) because automatically having the fk's generated mean less coding and less complicated LINQ queries.
   
2. The ability to add stored procedures as methods to your database context. This is really cool. You can add all of your table objects to the database context and then you can also drag and drop stored procedures. These stored procedures are then generated as methods on the database context class with strongly typed parameters. This can lead to a cleaner implementation of your data layer classes since you can create database contexts for related groups of tables and then add the stored procedures that deal with those table objects inside the database context. This leads me to one final point.

Although I am impressed by LINQ to SQL, it does raise some interesting data layer architecture questions and makes me wonder about potential for abuse. I am experimenting with some ideas for data layer designs to see what will work the best, but really only time will tell as I use LINQ on larger projects. Also, I can see where many developers (myself included) will be tempted to access to db in layers other than DAL since it will be so easy with LINQ to SQL.