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.

How to include the SharePoint version in a Word document

I’m currently working with our client’s legal department to build a case and document management solution based on SharePoint 2010.

Most of our requirements will be solved with plain OOB functionality. However, we were quite surprised to figure out that there is no easy way to add the SharePoint version number to our Word documents. When printing a document, it would be very helpful to have the version number printed on the footer, to know which version it is.

There are two workarounds for this, that I know about:

Solution 1: Use label information management policy

Add a label information management policy on the library as described in this thread. Unfortunatley, there are a few issues with this solution.

First of all it requires SharePoint Server, since information management policies are not included in SharePoint Foundation.

Secondly, it requires quite a few manual steps that most end users won’t feel to comfortable with.

Also, it seems that adding an information management policy breaks the ‘Save as site template’ functionality. We’re waiting for Microsoft support to clarify if this is a bug or expected behavior.

Solution 2: Create an event receiver

The second options is to create an event receiver that copies the version number to an additional SharePoint text column. The additional column is then available to add as a quick part in Word.

This solution doesn’t require a server license, but it does require some custom code.

Fortunately, there is a handy CodePlex solution for this. The best thing with the SharePoint 2010 version is that it’s available as a sandboxed solution. So it’s really easy to install and get up and running.

This is probably the best solution until Microsoft fixes this limitation.

Finally, I would say that this is more of a Word issue than a SharePoint issue. The information about the SharePoint version number is indeed available in Word, so there is no reason why it can’t be available as a quick part.