This post is preliminary and is subject to change, but should give you at least an idea. It refers to build 14.0.4006.1010.
In SharePoint 2007 you have to user CAML to query SharePoint lists. Anybody who have already written CAML queries knows that this can be tedious with complex queries. To make life easier the community had developed various helper tools like the U2U CAML Query Builder, YACAMLQT (Yet Another CAML Query Tool), CAML.NET… Meanwhile .NET 3.5 has been released with a cool new feature called LINQ (Language Integrated Queries). LINQ allows you to query in an object-oriented way, supports compile-time check, gives you intellisense support in Visual Studio and defines a unified, SQL like syntax to query any data source.
var result = from c in Contacts where c.FirstName == "Christian" select cThe abstraction to allow querying any data source has been implemented through an interface called IQueryable(T), but don’t want to go deep in LINQ. Since now Microsoft has been delivered four LINQ providers:
- LINQ to Object
- LINQ to XML
- LINQ to SQL
- LINQ to Entity
To don’t overlook the community efforts, there is already a LINQ provider for SharePoint on CodePlex, but since now it is in an alpha stadium.
LINQ to SharePoint
LINQ to SharePoint works similar to LINQ to SQL or LINQ to Entity. You write business objects (or maybe a DAOs) and decorate them with mapping attributes. When the query will be executed the LINQ statements will be translated to CAML.
The example class Contact maps to a custom Content Type with the name MyContact and the columns ID and FirstName. Writing this manual is cumbersome, therefore there’s a command line tool called SPMetal, which generates this classes for a whole site. E.g:
SPMetal /web:http://localhost/anysite /namespace:iLoveSharePoint /code:SPDataContext.cs
Now we want to query our SharePoint list with LINQ. This is done by a class called Microsoft.SharePoint.Linq.DataContext. The DataContext represents a whole web site. SPMetal additionally generates a derived DataContext containing all lists as Properties.
Certainly you can add, edit and delete items with LINQ to SharePoint. To enable change tracking you must (not really all) implement some interfaces in your class:
Adding, editing and deleting Items with LINQ to SharePoint
The method SumbitChanges of the DataContext persist all changes (add, edit, delete) to the SharePoint Content DB.
Another hot topic in SharePoint are relations between lists. In SharePoint 2007 CAML hasn’t any support for joins! This have made it almost impossible to build data centric applications for SharePoint 2007 (among other restrictions). But many, many customer want do that! Now with LINQ to SharePoint comes support for relational queries – Yippee!
Relations in LINQ to SharePoint
Now we extend our sample Content Type with a lookup column to another Content Type called MyCountry and map the relation.
To map a multi Lookup you have to use EntitySet<T> instead of EntityRef<T> and set the MultivalueType property of the Association attribute to Multi. The loading of the relation is deferred. The Country object of the Contact will be loaded from the DB when the property will accessed and not before.
Get all contacts from Germany:
Yet I haven’t verified that this relational query really ends up in a SQL joins If not, this would really be bad. I will verify that as soon as possible…
I think I stop here, because things could change in further builds…