Is it recommended to use Linq to SharePoint while developing projects for SharePoint 2013? or this became an old trend?
As is mentioned often, it provides strongly typed objects, which when using we get intellisense while coding. So, our code will be more bug free unlike the CAML Queries where the result will be known only in the run time.
One 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.
We can also use LINQ to SharePoint to generate some complex CAML queries as shown in this blog
During the run time the LINQ query itself gets converted into a CAML query, which is an extra step ahead that takes more time . This can be avoided if we write a CAML query itself straight away.
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 is not generated dynamically. So, if we do any changes in any of the lists or libraries in our site it is not reflected in the DataContext class. We have to generate a new class whenever we make any changes in the site.
Unlike CAML queries, LINQ to SharePoint has no use if we are going to access SharePoint data in Silverlight using Client Object Model.
Fields like Created, CreatedBy, Modified and ModifiedBy of a SharePoint list are not created by SPMetal to be used in the LINQ queries.
LINQ to SharePoint cannot be implemented for an External list.
It is depend upon on your choice but on average LINQ is not recommend.
Bad: LINQ relies on providers (or drivers) to access its data, as a developer you get many of the same problems that developers working against hardware get.
there’s no way for you to control how the provider works either, unless you understand intimately how that specific provider handles queries. There’s really no way to optimize a LINQ query without knowing both how the provider works and how the underlying data source works.
Even though the LINQ interface to SharePoint seems lucratively easy-to-use, it should be used with caution, especially at performance-critical parts or when dealing with potentially large lists