Background: Linq to Sql is a lightweight data access protocol for the .Net framework. It supports filtering and other lambda features in code, allowing the programmer to treat their data source as if it were a collection of objects that support flexible features. In this way, it can be thought of as an ORM mapper, though some might dispute that. Disclaimer: That is my own oversimplified definition.
I like what I see out of Linq to Sql. It shows a lot of potential, and the transference of knowledge that should happen when using other forms of Linq (xml, objects) is a nice benefit. However, there are a lot of questions raised in the community like the following:
http://odetocode.com/Blogs/scott/archive/2008/11/10/12311.aspx
I’ve been in several debates over this. My concern isn’t that Linq to Sql is bad, but there are serious maintainability issues around code that uses dead Microsoft features. In the open source world, as long as community members want to use a feature, it will be around. Trying to get help from a black-listed feature from vendors, consultants, and community members in the Microsoft world isn’t so easy. You certainly aren’t going to see Microsoft spend time and money adding interop hooks for features that have fallen out of favor. And how many of your junior programmers five years from now are going to be familiar with a feature from .Net 3.0/3.5 that is shunned in the version du jour.
Everytime I think about using such a feature, I think of the excited J# developers of the early 2000’s.