LINQ to SharePoint is not a substitute for a repository

LINQ to SharePoint is a nice new feature of SharePoint 2010, which offer both strongly typed access to SharePoint list data, as well as translation between LINQ and CAML queries. Even though this makes data access against lists a lot easier than before, there are a few things to keep in mind before deciding to use this in your solution.

First of all, LINQ to SharePoint is NOT a substitute for a repository. The SPMetal objects that are returned from the LINQ queries are basically just strongly typed representations of the list item objects. If you need change the structure of your list, you will have to update the SPMetal classes which will cause problems of you have a lot of dependencies to these classes in your code. Using LINQ to SharePoint directly from your UI components can lead to just as unmaintainable solutions as those built on LINQ to SQL.

A lot better option (see the image on the right side) is to create your own domain classes, create a mapping between your domain class and SPMetal class and encapsulate this together with the data access code in a repository. If anything changes in the list item structure, you will only need to update the mapper and SPMetal classes, nothing else.

Also, be aware that using LINQ to SharePoint may cause a performance overhead. We have done some simple performance measurement where we compare data access through LINQ with ‘classic’ style SPQuery. SPQuery actually performs a lot better. Two possible reasons are overhead in query translation from LINQ to CAML and the mapping between SPListItem and SPMetal object. Since the overhead is just as big when executing queries that return zero items, the query parsing and translation is the most likely cause of the performance penalty.

Of course, you can also still build your repository in the same manner as SharePoint Guidance for SharePoint 2007, with your own List Item mappers and CAML queries embedded in the repository.

There are a few options here, which is probably the best argument for building a repository that returns instances of your own domain classes rather than the SPMetal generated classes. If you do that, you are free to change the internal implementation and storage model without impacting the rest of your solution.