Microsoft SharePoint 2010 brings support for Language-Integrated Query (LINQ) to the platform, which can improve the productivity and efficiency of developers reading and writing to SharePoint lists. However, many SharePoint developers don’t have a firm grasp of how LINQ works. So, I’ll provide a brief LINQ primer, then jump into how to use LINQ in SharePoint 2010 projects. I’ll then explain a limitation with the SharePoint-generated entity models and provide a solution for how to get around it.
A Brief LINQ Primer
Like all other platforms, SharePoint provides different ways for developers to read and write data in SharePoint sites. Developers use lists to store data in SharePoint sites, similar to how developers use tables to store data in Microsoft SQL Server databases. In the past, developers had to use different data access technologies to access the data on the various platforms. For example, developers had to use T-SQL to access SQL Server data, Collaborative Application Markup Language (CAML) to access SharePoint data, and XPath to access XML data. These data access technologies are very different and challenging to switch between.
To make it easier for developers, Microsoft introduced LINQ as part of the Microsoft .NET Framework 3.5. LINQ defines standard query operators that developers can use to create standard queries. Out of the box, LINQ supports querying against any object collection that implements the IEnumerable<T> interface. This is because the compiler can interpret the query by examining the data source, the collection of objects, when projects are compiled.
However, in the case of data sources such as SQL Server, SharePoint, and XML, the compiler doesn’t know what the data source structure looks like. To address this, LINQ supports a provider model. Developers can create a provider that tells LINQ how to translate a LINQ query into something the data source understands. For example, the LINQ to SQL provider knows how to translate a LINQ query into a T-SQL query. For this to work, the compiler needs to understand the structure of the data source. This is done by using a special utility to create an entity model. An entity model is a code representation of the data source.
When working with SQL Server, developers use SQLMetal.exe to generate the entity model. This utility is run against the database and generates a code file that is added to the project. Developers then write queries against the entity model in the project. The entity model also enables Visual Studio (VS) to provide IntelliSense when writing queries.
LINQ for SharePoint
Although Microsoft Office SharePoint Server 2007 (MOSS 2007) SP1 added support for the .NET Framework 3.5 SP1, it didn’t add support for LINQ. So, there was no native support for writing LINQ queries against SharePoint lists and libraries.
The SharePoint 2010 product team changed this by including the LINQ to SharePoint provider and the SPMetal.exe utility. SharePoint 2010’s new support for LINQ can dramatically improve SharePoint developers’ productivity. For example, instead of having to write the cumbersome CAML queries, SharePoint developers can write LINQ queries. At compile time, the LINQ queries will be translated to CAML queries.
To use LINQ queries in SharePoint projects, developers must first create an entity model with SPMetal.exe. This utility creates an entity model based on a specific SharePoint site. By default, it creates models for all of the lists in the specified site. However, developers can pass in an XML file that specifies which lists to generate models for.
The generated entity model includes an object for each type of list as well as a collection to store items. For example, the entity model for a Customers list that’s based on the Contacts template will have the CustomersContact object as well as the Customers collection. The CustomersContact object will contain properties representing the fields in the Customers list. Developers can use the object and its properties to create, update, delete and select items from the Customers list. However, they might find that some fields don’t have matching properties because of a limitation in SharePoint-generated entity models.