das Client Object Model

Bereits bei früheren SharePoint-Versionen gab es ein umfangreiches Objektmodell, das zum Beispiel den Zugriff auf eiine Site oder einzelne Listen ermöglichte. Es handelte sich aber um ein rein serverbasiertes Modell. Client-Anwendungen mussten ein wenig umständlich über eine Webservice-API auf die Funktionalität des SharePoint-Servers und seine Daten zugreifen. Da Web-Anwendungen zunehmend mit clientseitigen Technologien wie Ajax oder Silverlight "aufgebohrt" werden, die dem Benutzer das Gefühl einer Rich-Client-Anwendung vermitteln sollen, führte Microsoft in SharePoint 2010 das Client Object Model (Client OM) ein. Wie es die Bezeichnung vermuten lässt, handelt es sich um ein Objektmodell, das ein lokaler Client benutzen kann, um via JavaScript oder .NET-Managed Code in einer Silverlight-App auf SharePoint-Funktionen und -Daten zugreifen können. Bemerkenswert ist, dass Microsoft das Client OM innerhalb der SharePoint-2010-Benutzeroberfläche selber intensiv nutzt. Bei der Benutzerführung wird dies an vielen Stellen durch eine deutlich reduzierte Anzahl an Page Refreshes angenehm spürbar. Das Client-OM in drei Ausprägungen Das Client Object Model gibt es in drei unterschiedlichen Ausprägungen für .NET (zum Beispiel WPF, WinForms oder Office-Add-Ins), für Silverlight und für JavaScript (verwendbar auf SharePoint-Seiten, im Dialog Framework und in Web Parts). Alle drei Varianten arbeiten nach demselben Muster und unterscheiden sich nur marginal. Die Microsoft-Entwickler haben darauf geachtet, dass die Konzepte und Namespaces des Client OM so weit als möglich demjenigen des vielen Entwicklern bereits vertrauten serverseitigen Objektmodells entsprechen. Erfahrene SharePoint-Entwickler werden sich daher im Client OM schnell heimisch fühlen. Trotz dieser Ähnlichkeiten gibt es aber auch wesentliche Unterschiede. So ist der Funktionsumfang im Vergleich zum serverseitigen Objektmodell deutlich abgespeckt. Immerhin stellt das Client OM Klassen zum Durchführen der wichtigsten Aufgaben innerhalb einer Site Collection bereit. Dazu gehört etwa der Lese- und Schreibzugriff auf Objekteigenschaften und List-Items, das Erstellen von Sites und Listen oder das Manipulieren von WebParts und Menü-Items. Nicht unterstützt werden Funktionen, die außerhalb des Scopes einer Site Collection liegen. Auch auf die vielen Administrations-Funktionen des Server-Objektmodells hat man via Client-API keinen Zugriff.Abb. 1 illustriert wie das Client OM im Hintergrund funktioniert. Für die Kommunikation mit SharePoint-Server steht ein WCF-Service (unter /_vti_bin/client.svc) bereit. Die über das ClientContext-Objekt gebündelten Abfragen werden zunächst intern in CAML umgewandelt und als XML-String an den Service übermittelt. Die angeforderten Daten werden als JSON-Paket zurückgeliefert, auf dem Client ausgewertet und an Objekte der Anwendung übergeben. Abb. 1: Ein WCF-Service wickelt die Kommunikation zwischen Client und Server ab. Die Resultate im JSON-Format werden vom Client OM selbständig ausgewertet Der ClientContext als EingangstürDer zentrale Einstiegspunkt in die Welt der clientseitigen SharePoint-Programmierung ist das ClientContext-Objekt. Dieses ist nicht nur für die Herstellung einer Verbindung zwischen Client und SharePoint-Site verantwortlich, sondern es handhabt die Authentifizierung und die Ausführung des Codes auf dem Server.Das Codebeispiel in Abb. 2 zeigt die Durchführung einer einfachen Abfrage aus einer Konsolenanwendung via Managed Code. Zunächst wird über den Konstruktor der ClientContext-Klasse die SharePoint-Site festgelegt (Zeile 13). Danach wird mit der Load()-Methode des ClientContext-Objektes spezifiziert, welche Informationen vom Server bezogen werden sollen. In diesem Beispiel ist es eine SharePoint-Site mit der Adresse http://sps2010 und die darin enthaltene Liste mit der Bezeichnung "Tasks" (Zeilen 18 bis 19). Wichtig: Bis zu diesem Zeitpunkt wurde noch keine Abfrage an den Server geschickt, sondern lediglich festgelegt, welche Daten vom Server geladen werden sollen. Die eigentliche Anforderung der Daten wird erst durch den Aufruf ExecuteQuery()-Methode ausgelöst (Zeile 21). Dank dieser Technik kann die Anzahl der Roundtrips zum Server minimiert werden, da mehrere Abfragen zusammengefasst und in einem Rutsch vom Server geladen werden. Abb. 2: Die gewünschten Serverabfragen werden erst mit der Load()-Methode vorbereitet und anschliessend via ExecuteQuery() in einem Rutsch durchgeführt Gezielte DatenabfrageEin wichtiger Aspekt des Client OM ist, dass Entwickler sehr feinkörnig kontrollieren können, welche Daten vom Server zurückgegeben werden sollen. Im Codebeispiel in Abb. 2 werden nahezu sämtliche Properties des Web- und List-Objektszum Client zu übertragen, wodurch das übermittelte JSON-Paket unnötig aufgebläht und die Performance der Anwendung reduziert wird. Mit Hilfe einer Lambda-Expression lassen sich die zurückgegebenen Properties effektiv eingrenzen (Zeilen 18 bis 19). Das Codebeispiel in Abb. 3 veranschaulicht dieses Prinzip. Abb. 3: Lambda-Expressions geben an, welche Daten vom Server geliefert werden sollen Wesentlich mehr Flexibilität bei der Abfrage von Daten liefern Abfragesprachen wie CAML oder LINQ (Query Expression Syntax), die beide vom Client OM unterstützt werden. Der Einsatz einer der beiden Query-Technologien ist vor allem dann sinnvoll, wenn mit Datensätzen (z.B. den Items einer Liste) gearbeitet wird, die mit Hilfe der Abfragesprache gefiltert oder sortiert werden können. Das Codebeispiel in Abb. 4 zeigt die Verwendung einer CAML-Query, welche alle Items einer Taskliste ausgibt, deren Status auf "In Progress" gesetzt ist. Abb. 4: Eine Datenabfrage kann mit CAML-Queries effizienter gestaltet werden Als Alternative zur Load()-Methode stellt das ClientContext-Objekt die LoadQuery()-Methode zur Verfügung. Diese schreibt die angeforderten Daten nicht in das ClientContext-Objekt, sondern liefert eine neue IEnumerable-Collection zurück, die etwas mehr Flexibilität bietet. Im Gegensatz zur Load()-Methode kann LoadQuery() ausserdem mit LINQ Query Expressions (LINQ to Objects) verwendet werden (Codebeispiel in Abb. 5). Abb. 5: Die LoadQuery()-Methode kann LINQ-Queries verarbeiten und ein Objekt vom Typ IEnumerable zurückliefern Wie bereits angesprochen, können Daten nicht nur abgefragt, sondern auch manipuliert werden. Das funktioniert im Client Object Modell weitgehend auf dieselbe Weise wie beim serverseitigen Objektmodell. Dabei können nicht nur die Eigenschaften von SharePoint-Objekten überschrieben werden, sondern es lassen sich auch SharePoint-Inhalte zufügen oder löschen. Das Codebeispiel in Abb. 6 zeigt, wie sich Objekteigenschaften einfach überschreiben und anschliessend wieder auf den Server zurückschreiben lassen (Zeilen 36 bis 50). Abb. 6: Über das Client Object Model lassen sich Daten auch zurückschreiben oder neue Objekte hinzufügen Vielversprechende Möglichkeiten dank Client OM Das Client OM bietet viele weitere interessante Konzepte, die im Rahmen dieses Überblicks nur angedeutet werden können. Dazu gehören beispielsweise das Exception Handling, der Conditional Scope oder die asynchrone Verarbeitung von Serverabfragen, die für das Verwenden mit Silverlight und JavaScript erforderlich ist. Für SharePoint-Entwickler stellt das Client OM eine der interessantesten Neuerungen in SharePoint 2010 dar, die viele neue Möglichkeiten bei der Umsetzung von intelligenten UI-Konzepten und der Integration von Client-Anwendungen mit SharePoint eröffnet. Urs Bertschy ist Inhaber der Bertschy Informatik AG in Zug, die sich auf Beratung und Know-how rund um das Thema SharePoint spezialisiert hat. Sie erreichen den Autor über http://www.bertschy.ch/blog.Urs Bertschy