Um Daten aus Listen zu verarbeiten bietet SharePoint 2010 mit LINQ to SharePoint eine komfortable Alternative zu CAML-Queries. LINQ besitzt aber auch einige Nachteile.
LINQ bietet bei SharePoint 2010 mehr Komfort für das Abfragen von Listeninhalten
Die bislang geläufigste Methode für Datenoperationen in SharePoint-Listen war das Formulieren von CAML-Queries, die in Kombination mit SPQuery- und SPSiteDataQuery-Objekten verwendet wurden. Leider führt die XML-basierte CAML-Syntax insbesondere bei komplexeren Abfragen sehr schnell zu aufgeblähtem Code, der nicht nur schlecht lesbar, sondern sehr fehleranfällig ist. Weitere Nachteile sind die mangelnde Unterstützung für IntelliSense und dass Fehler im CAML-Code erst zur Laufzeit durch wenig aussagekräftige Fehlermeldungen quittiert werden. Alle diese Mankos werden durch LINQ to SharePoint ausgebügelt. LINQ (Language Integrated Query) ist eine mit .NET Framework 3.5 eingeführte, objektorientierte Abfragesprache, mit der Queries in einer an SQL angelehnten Syntax direkt im Programmcode formuliert werden können [1]. Die Vorteile: Typensicherheit, Prüfung durch den Compiler, IntelliSense bei der Formulierung von Abfragen sowie eine einheitliche Syntax für die Arbeit mit unterschiedlichen Datenquellen – etwa SQL Datenbanken, XML, ADO.NET Entity Framework, ADO.NET Data Services. Zwar gab es bereits für SharePoint 2007 einen LINQ-to-SharePoint-Provider, dieser wurde aber im Rahmen eines Community-Projekts entwickelt und von Microsoft nicht offiziell unterstützt. SharePoint 2010 bringt neu LINQ als Abfragetechnologie mit. Die Abfragen lassen sich kurz, knapp und elegant formulieren und werden bereits beim Kompilieren auf Fehler geprüft. Ein weiteres Plus: Die zurückgelieferten Objekte einer LINQ-to-SharePoint-Abfrage liegen in Form von typisierten Business Objekten (Entities) vor. Auch das Weiterverarbeiten wird komfortabler. Bevor man in den Genuss komfortabler Abfragen kommt ist etwas Handarbeit erforderlich. Um LINQ aus eigenem SharePoint-Code nutzen zu können, müssen zunächst Entity-Klassen generiert werden, welche die Listen und Items einer Site in Form von Business Objekten abbilden. Dies geschieht mit dem Tool SPMetal.exe, das im bin-Verzeichnis des SharePoint-Root-Folders (14\bin) zu finden ist. Der folgende Befehl generiert für jede Liste in der angegebenen SharePoint-Site die passenden Entity-Klassen: spmetal /web: /code:ProjectContext.cs Das generierte File umfasst neben den Entities auch eine DataContext-Klasse, die für die Verbindung zu den SharePoint-Daten zuständig ist (ähnlich der SqlConnection-Klasse bei ADO.NET) und sich um Dinge wie ein Change Tracking kümmert.
Nachdem man das generierte File in das eigene Visual-Studio-Projekt eingebunden und eine Referenz zur Microsoft.SharePoint.Linq-Assembly (unter 14\ISAPI) gesetzt hat, kann die Arbeit mit LINQ und den SharePoint-Daten losgehen. Das Codebeispiel im Bild zeigt eine einfache Abfrage, die alle Items einer Liste sortiert nach deren Status zurückliefert. Wer mehr Kontrolle über den durch SPMetal generierte Code haben möchte, kann diese über eine XML-Konfigurationsdatei Parameters.xml erlangen. Hier lässt sich unter anderem festlegen, welche Listen und Felder (Columns) in den erzeugten Entity-Klassen berücksichtigt werden sollen. Wer es noch komfortabler haben möchte, kann auch auf das Tool CKSDev zurückgreifen, das auf Mausklick die Entity-Klassen einer einzelnen Liste generieren kann. Das neue LINQ wird CAML als Abfragesprache in SharePoint nicht ablösen. Stattdessen fungiert der LINQ-to-SharePoint-Provider als eine Art «Abstraktionslayer», der die LINQ-Queries im Hintergrund in CAML-Abfragen übersetzt. Das sieht man sehr schön, wenn man die Log-Property der DataContext-Klasse verwendet, um den generierten CAML-Code auszugeben. Dieses Feature ist nicht nur für das Debugging hilfreich, sondern kann auch dazu verwendet werden, benötigten CAML-Code bequem via LINQ zu erzeugen statt manuell einzutippen.
Grenzen von LINQ to SharePoint
LINQ to SharePoint unterstützt ein breites Spektrum an Abfragemöglichkeiten. So lassen sich etwa Daten über mehrere verknüpfte Listen erstellen und es gibt eine ganze Reihe an Methoden, um die Ergebnisse filtern, aggregieren oder gruppieren zu können. Zudem werden auch die «Query Compositions» unterstützt, über die auf die Ergebnisse einer Abfrage eine weitere LINQ-Query durchgeführt werden kann. Des Weiteren erlaubt LINQ to SharePoint auch das Zufügen, Löschen und Aktualisieren von Daten in SharePoint-Listen. LINQ to SharePoint besitzt allerdings eine Reihe von Nachteilen. Der wohl Grösste ist, dass mit SPMetal generierte Objekte unter Umständen unbrauchbar werden, wenn an den verwendeten Listen Änderungen am Schema – etwa durch Zufügen oder Löschen von Feldern – gemacht werden. Da solche Anpassungen von Site-Administratoren und je nach Sicherheitskonzept auch von Power- oder Endbenutzern vorgenommen werden können, ist hier besonders viel Vorsicht geboten. Ein weiteres Minus: Es gibt Einschränkungen beim Formulieren von LINQ-Abfragen und es werden auch nicht alle Möglichkeiten von CAML unterstützt. So ist das Durchführen von Abfragen über eine ganze Site Collection hinweg (via CAML und das SPSiteDataQuery-Objekt realisierbar), nicht so ohne weiteres möglich. Auch fehlt die Möglichkeit, das neu in SharePoint 2010 eingeführte List Throttling zu kontrollieren, das für eine bessere Handhabung von grossen Datenmengen gedacht ist. Für das Verarbeiten von Listendaten wird LINQ to SharePoint in vielen Fällen ausreichen und bietet dem Entwickler dabei ein deutliches Plus an Komfort und Produktivität. Dort wo LINQ an seine Grenzen stösst, kann weiterhin CAML-Queries gearbeitet werden. Urs Bertschy ist Inhaber der auf Web- und SharePoint-Consulting/-Development spezialisierten Bertschy Informatik AG. Unter www.bertschy.ch/blog unterhält er einen Technologieblog, der sich vor allem SharePoint-, aber auch anderen IT-Themen widmet.
