Share Point Server 2010 - Das Entwicklerbuch

2 Das SharePoint-Objektmodell

Das SharePoint-Objektmodell ermöglicht einen vollständigen Zugriff auf alle Funktionen und Inhalte einer SharePoint Farm. Alle Aktionen, die über die SharePoint-Oberfläche durch einen Benutzer durchgeführt werden können, sind auch über das SharePoint-Objektmodell realisierbar. Daher ist es für einen SharePoint-Entwickler essenziell wichtig, das Objektmodell und dessen Aufbau zu kennen. Da das verfügbare Objektmodell die vollständige Kontrolle und Interaktion mit dem SharePoint Server zulässt, ist es auch entsprechend umfänglich. Das Objektmodell ist in ca. 50 Namensräumen (Namespaces) gegliedert, wobei lediglich 16 davon für die normale SharePoint-Entwicklung relevant sind. Zudem sind einige Verwendungsregeln zu beachten, wenn aus eigenem Code heraus auf das Objektmodell zugegriffen wird. Dieses Kapitel gibt im ersten Teil einen Überblick über die SharePoint-Struktur, und im zweiten Teil werden die verschiedenen verfügbaren Objektmodelle erläutert.

Hinweis: Die einzelnen Beispiele stellen nur einen kleinen Ausschnitt der Möglichkeiten dar, die mit dem vorhandenen Client/Server-Objektmodell umgesetzt werden können. Die einzelnen Kapitel in diesem Buch verwenden jeweils unterschiedliche SharePoint-Funktionen. Ziel der Beispiele ist es, die generelle Funktionsweise und die Möglichkeiten aufzuzeigen. Auf eine detaillierte Aufzählung aller Klassenmitglieder wurde bewusst verzichtet. Sie können der (Online-)MSDN-Bibliothek entnommen werden.

2.1 SharePoint-Struktur

Wie jedes andere Server- bzw. Anwendungssystem besitzt auch SharePoint eine Systemarchitektur. Im SharePoint-Bereich existieren zwei wesentliche Architekturmodelle bzw. Architektursichten. Zum einen handelt es sich dabei um die physikalische Serverarchitektur und zum anderen um die logische Seitenarchitektur, die auch als Seitenhierarchie bezeichnet wird. Um ein gutes Verständnis für das eigentliche Objektmodell zu erhalten, ist es im Vorfeld wichtig, die Server- und Seitenarchitektur zu verstehen. Sind diese Architekturen bekannt, kann daraus sehr gut das Objektmodell abgeleitet werden. Anhand der beiden Architektursichten werden die verschiedenen Objektabhängigkeiten deutlich und ermöglichen so eine einfache Navigation zwischen den Objekten. Dies ist ein wenig vergleichbar mit einem klassischen Datenbankmodell und den darin enthaltenen Tabellen. Erst wenn die Datenbankstruktur bekannt ist, können effizient Daten verknüpft und abgerufen werden. In den beiden folgenden Kapiteln werden daher die beiden Architekturen erläutert.

Hinweis: Das obere Datenbankbeispiel bezieht sich nicht auf die internen SharePoint-Datenbanken. Diese Datenbanken sollten niemals direkt manipuliert werden. Jegliche Änderungen müssen immer über das Objektmodell – also das API – durchgeführt werden.

2.1.1 Serverarchitektur

Die Serverarchitektur beschreibt die physikalische Verteilung einer SharePoint Farm. Dabei stehen die einzelnen Server im Mittelpunkt der Betrachtung. Im ersten Kapitel wurden die verschiedenen Möglichkeiten für eine SharePoint-Entwicklungsumgebung dargestellt. Werden alle Komponenten auf einem Server installiert, besteht die gesamte Serverarchitektur lediglich aus einem Server. Bei größeren Bereitstellungen im Enterprise-Umfeld sieht es allerdings schon anders aus. So finden sich im Enterprise-Umfeld nicht selten Anforderungen, mehr als 10 000 Benutzer unterstützen zu müssen. Das ist nur dann möglich, wenn die SharePoint Farm entsprechend groß dimensioniert ist. Die verschiedenen Serverrollen werden also auf mehrere Server physikalisch verteilt. Mithilfe der Serverarchitektur kann die notwendige Verteilung geplant und beschrieben werden. Abbildung 2.1 zeigt dazu eine typische SharePoint-Foundation-Serverarchitektur. Nachfolgend werden die einzelnen Bestandteile und die zugehörigen Klassen aus dem Objektmodell beschrieben. Detaillierte Informationen zu den einzelnen Klassen sind in den Unterkapiteln 2.2 und 2.3 zu finden.

Abbildung 2.1: SharePoint-Foundation-Serverarchitektur 1

Wie erkennbar ist, steht an oberster Stelle der Architektur die SharePoint Farm. Ein programmatischer Zugriff ist über das korrespondierende Objekt SPFarm möglich. Über ein gültiges SPFarm-Objekt können über die Eigenschaft Servers die verfügbaren Server abgefragt werden. Die Eigenschaft Servers gibt dazu eine Liste von SPServer-Objekten zurück. Jedes Objekt repräsentiert einen physikalischen Server aus der zugehörigen SharePoint Farm. Die einzelnen verfügbaren Dienste auf einem physikalischen Server sind über die Eigenschaft ServiceInstances abrufbar, die eine Liste von SPServiceInstance-Objekten enthält. Eine Instanz vom Typ SPDatabaseServiceInstance stellt eine einzelne Instanz eines Datenbankdienstes dar. Die Klasse SPDatabaseServiceInstance stellt die Eigenschaft Databases bereit, über die alle verfügbaren Inhaltsdatenbanken abgerufen werden können. Weiterhin ist über das SPFarm-Objekt ein Zugriff auf alle Web Services möglich. Dazu enthält das SPFarm-Objekt die Eigenschaft ServiceInstances, die eine Liste von verfügbaren SPService-Objekten zurückgibt. Ein gültiges SPService-Objekt ermöglicht den Zugriff auf Konfigurationseinstellungen eines logischen Dienstes oder einer Anwendung. Die SPService-Klasse besitzt die Eigenschaft WebApplications, über die eine Liste aller zugeordneten Webanwendungen abgerufen werden kann. Die Liste enthält dazu Objekte vom Typ SPWebApplication. Jede dieser Instanzen stellt eine Webanwendung bereit, die im Microsoft Internet Information Server (kurz: MS IIS) betrieben wird. Für den SharePoint-Entwickler beginnt es in der Regel ab dieser Stelle interessant zu werden, da über die SPWebApplication-Eigenschaft Sites der Zugriff auf die zugehörigen Site Collections möglich ist. Die ab hier beginnende Seitenarchitektur wird im nächsten Kapitel erläutert.

2.1.2 Seitenarchitektur

Die Seitenarchitektur beginnt unterhalb der Webanwendung beim SPSite-Objekt. Obwohl die Klasse SPSite im Singular benannt ist, handelt es sich in Wirklichkeit um eine Auflistung in Beziehung stehender SPWeb-Objekte. Abbildung 2.2 verdeutlicht diesen Sachverhalt. Die Namensgebung der beiden Klassen SPSite und SPWeb führt leider des öfteren zu Irritationen, daher wird an dieser Stelle detaillierter auf diese beiden Klassen eingegangen.

Abbildung 2.2: Sitehierarchie 2

SPSite

Laut der MSDN-Beschreibung stellt ein SPSite-Objekt folgenden Kontext dar:

„Represents a collection of sites in a Web application, including a top-level Web site and all its subsites. Each SPSite object, or site collection, is represented within an SPSiteCollection object that consists of the collection of all site collections in the Web application.“ 3

Bei der SPSite-Klasse handelt es sich aber nicht selbst um eine Auflistungsklasse, da die Klasse lediglich von der allgemeinen Object-Klasse erbt. Auch besitzt die Klasse kein visuelles Gegenstück im SharePoint-Portal, sondern stellt lediglich eine Liste mit zugehörigen SPWeb-Instanzen bereit. Zusätzlich stellt die Klasse über die Eigenschaft RootWeb die oberste Webseite zur Verfügung.

SPWeb

Bei der Beschreibung der SPWeb-Klasse ist die MSDN-Dokumentation dagegen kurz und knapp und beschreibt die Klasse wie folgt:

„Represents a SharePoint Foundation Web site. 4

Diese Beschreibung ist klar und verständlich. Jede Instanz einer SPWeb-Klasse stellt eine Webseite dar und besitzt somit auch ein visuelles Gegenstück im SharePoint-Portal. Die Klasse erbt – genau wie die SPSite-Klasse – von der allgemeinen Object-Klasse. Somit haben die beiden Klassen SPSite und SPWeb objekttechnisch nichts miteinander gemeinsam.

SPSite und SPWeb

Die beiden Klassen sind objekttechnisch zunächst unabhängig voneinander. Dennoch stehen sie in einer logischen Beziehung. Um diese Beziehung zu verdeutlichen, werden die folgenden Adressen eines fiktiven SharePoint-Portals den beiden Klassen zugeordnet:

a) http://sharepoint/

b) http://sharepoint/department

c) http://sharepoint/department/Internal/

Im Fall a) handelt es sich um die Adresse einer Seitenauflistung (Site Collection) inklusive einer (Wurzel-)Webseite (Root Web Site). Der URL aus Punkt b) bezieht sich auf eine Unterwebseite (Sub-Site) von a). Die letzte Adresse ist ebenfalls eine Unterwebseite (Sub Web Site) der Seitenauflistung von a). Der Pseudocode in Listing 2.1 bildet die Adressen auf entsprechende SharePoint-Objekte ab.

Listing 2.1: Pseudocode

Bei der...