Steve Michelotti

LINQ to SQL Again??

Steve Michelotti -

Tomorrow night I'll be at RockNUG presenting LINQ to SQL. Yes, LINQ to SQL. Again. In the last 2 years I have presented LINQ to SQL numerous times at various user groups and code camps. Why do I keep getting asked to present LINQ to SQL? Isn't LINQ to SQL dead? Answer: No.  LINQ to SQL is not dead!

This confusion all started back in October 2008 with a seemingly innocuous post on the ADO.NET team blog discussing the emphasis that Microsoft was going to put into the Entity Framework going forward.  The developer community was immediately up in arms about this post for a variety of reasons.  First, many developers and companies had already made a significant investment in developing with LINQ to SQL.  Secondly, LINQ to SQL is great so why de-emphasize it?  Third, the Entity Framework has had its share of challenges getting acceptance in the development community (and I'm being charitable) so the thought of replacing something "good" with something "not as good" was not met with enthusiasm.

This led to a "clarification message" by the ADO.NET team a few days later in which they clearly state: "LINQ to SQL is not dead." This post may have been a somewhat weak defense of LINQ to SQL but the message was clear nonetheless. We've also seen others from Microsoft strongly advocate LINQ to SQL.  For example, in this MVC presentation at MIX 09, Scott Hanselman states he's using LINQ to SQL in the demo "because it's awesome and it's not dead." This all leads to a somewhat confusing state of affairs because we find ourselves relying on quotes from a respected Microsoft guru like Scott Hanselman and others in an attempt to translate Microsoft's marketing approach for their latest data access strategy. After all, one of the longest running jokes is that the last thing Microsoft needs is yet another data access framework.

So how do we make this pragmatic decision for ourselves when deciding on a data access strategy/framework? Although there are numerous data access choices, the top three frameworks that are typically examined are: 1) LINQ to SQL, 2) NHibernate, and 3) the Entity Framework (EF).

The Entity Framework vNext that will be released after .NET 4.0 looks very promising.  Model first, POCO code only, foreign key relationships, and more make me enthusiastic to give EF another run next year.  But…that's next year. If you're starting development on a new application today, you might think twice.

NHibernate is a great framework. No dispute there. On it's own it's solid but then when you add features such as Fluent NHibernate and LINQ to NHibernate it's becomes an extremely compelling choice. However, there is a steeper learning curve with NHibernate as compared to some other frameworks such as LINQ to SQL.  Additionally, some organizations (unfortunately) have policies against using open source software which disqualifies NHibernate in those environments.

Then you've got trusty ol' LINQ to SQL. In the last year, LINQ to SQL has continued to provide a solid data access choice. I strongly agree with the numerous points that Ian Cooper made in this post showing support for LINQ to SQL. In short, there are numerous reasons to learn and use LINQ to SQL. Among them:

  • LINQ to SQL is a stable release and has withstood the test for 2 years now. You don't have to wait for the next release (like EF) – you can use it now.
  • Open source is not always an option (depending on your environment). LINQ to SQL is good to go here.
  • The skills you learn in LINQ to SQL are transferrable.  In other words, if you learn LINQ to SQL now and later decide to switch to EF next year, you won't be starting from scratch. Your knowledge will be transferrable.
  • There are also some cool OSS projects for LINQ to SQL such as Fluent LINQ to SQL.

And finally, LINQ to SQL is just flat out good. While it may not be perfect (no framework is) the designers of LINQ to SQL inside Microsoft really got far more right than wrong when creating LINQ to SQL. You can use it with a RAD designer or you can hand code all your classes.  You can use it with C# attributes for mapping or external XML mapping files (or fluent mapping with OSS libraries). You can use it with auto-generated SQL or stored procedures. You can use it with POCO classes. You can use it in an N-Tier application without having to worry about serialization of your entities. It supports lazy loading or eager loading. The list goes on.

Having implemented numerous production applications with LINQ to SQL, I'm happy with it. But I'll continue to learn more about it and other data access technologies as well as they come out.

If you're in Rockville tomorrow night and have a desire to start learning LINQ to SQL, come on out!