The LINQ to SharePoint functionality which was available as a third party tool for free in codeplex for MOSS 2007 is available as an inbuilt functionality in SharePoint Server 2010.
I’m not going define what LINQ to SharePoint is as it is out of the scope of this post. I’m going to list out the advantages and the disadvantages of LINQ to SharePoint over CAML queries that I have been facing (though there are lots of blogs covering this topic). Let us see the advantages first.
1. As mentioned everywhere it provides strongly typed objects using which we get intellisense while coding. So, our code will be more bugs free unlike the CAML Queries where the result will be known only in the run time.
2. One more advantage not mentioned generally is that we can compare two columns (fields) of a SharePoint list in LINQ queries which is not possible in CAML queries.
3. We can also use LINQ to SharePoint to generate some complex CAML queries as shown in this blog
1. During the run time the LINQ query itself would get converted in to a CAML query which is an extra step ahead that takes some more time, which can be avoided if we straight away write a CAML query itself.
2. Also, we generate a DataContext class using the SPMetal.exe. This class is the one which we use in our project to generate LINQ queries. This class does not get generated dynamically. So, if we do any changes in any of the lists or libraries in our site it does not get reflected in the DataContext class. So every time we have to generate a new class whenever we make any changes in the site.
3. LINQ to SharePoint has no use if we are going to access SharePoint data in Silverlight using Client Object Model unlike CAML queries.
4. Default fields like Created, CreatedBy, Modified and ModifiedBy of a SharePoint list are not created by SPMetal to be used in the LINQ queries.
Update: This article describes on how to achieve this.
5. LINQ to SharePoint cannot be implemented for an External list.