With the release of the 3.5 extensions to the framework, there has been a lot of talk about LINQ and with it LINQ to SQL. Well I was interested in more how LINQ to SQL actually worked so I decided to take a look at some of the files it generates in the process and talk about them. When it comes down to it, in a lot of ways LINQ to SQL is just a glorified typed dataset with the power of LINQ behind it. Microsoft refers to it as an OR/M tool but everything is abstracted by the designer which means you can't create your own classes. This makes you completely data centric. Which is obviously fine for some situations, but not in all. Again, I am writing about what I am seeing and making some speculation, so if I am wrong, feel free to leave a comment and correct me like the noob I am.
I am not going to discuss how to use LINQ to SQL today since Scott's 9 part series of posts on it does an awesome job of getting started with it. I am going to talk about what it actually does under the covers. When you first, create a new LINQ to SQL Class, you will immediately notice it looks a lot like the designer for the ASP.NET 2.0 DataSet. You can drag over tables just like you do with a dataset. Behind the .dbml file of your LINQ to SQL class is a .dbml.layout file and a .designer.cs file. The layout file simply keeps track of where you put things in the desginer. The .designer.cs files is a bit more interesting. This is where your DataContext is created as well as classes for the tables you drug into the designer.
In the designer.cs file you will see multiple classes (a DataContext and one for each table you added). You'll immediately notice that it's a lot cleaner than the code behind of a typed DataSet. The DataContext class presents the means for LINQ to actually access the database and get the data you need. When you start looking at the autogenerated classes for your tables, you will find it has attributes similar to what you see on other OR/M. Here is what a class definition looks like.
[Table(Name="dbo.SecureColumns")]
public partial class SecureColumn : INotifyPropertyChanging, INotifyPropertyChanged
A typical property has attributes that tell it where in the database the column is mapped to. It also calls events before and after the property changes.
[Column(Storage="_Id", AutoSync=AutoSync.OnInsert, DbType="Int NOT NULL IDENTITY", IsPrimaryKey=true, IsDbGenerated=true)]
public int Id
{
get
{
return this._Id;
}
set
{
if ((this._Id != value))
{
this.OnIdChanging(value);
this.SendPropertyChanging();
this._Id = value;
this.SendPropertyChanged("Id");
this.OnIdChanged();
}
}
}
For the most part that's really all there is too it. I really wish it had support for you to map things to an existing domain object, but unfortunately there is nothing like that presently. Will people actually use LINQ to SQL? Who knows? You don't have a lot of control of the domain object it produces, but you can always extend them using partial classes. It definitely is a lot more feasibly to extend these than the crap that a typed dataset produces. What do you all think? Does LINQ to SQL have a chance?
Read the complete post at http://www.dotnettipoftheday.com/blog.aspx?id=397