Datenzugriff in SharePoint: Property Bag

23. Juli 2012

Dies ist der dritte Teil einer Serie, die sich mit der Frage beschäftigt auf welche Arten Konfigurationen in Applikationen unter SharePoint gespeichert werden können. Es wird zuerst immer kurz die Methode vorgestellt, gefolgt von einem kurzen Beispiel und den Vor- und Nachteilen.

Eine vollständige Übersicht über bisherige und noch folgende Artikel ist hier zu finden.

Die zweite Teil dieser Serie beschäftigt sich mit der Möglichkeit Konfigurationswerte in einem Property Bag abzulegen.

Das Property Bag ist ein Hashtable zum Ablegen von key/value Paaren. SharePoint verwendet das Property Bag selbst um z.B. die Versionsnummer oder auch die Verwendung von SharePoint Designer zu speichern.

Je nach Ebene auf der man sich befindet gibt es ein eigenes Property Bag. Es ist also möglich Werte für die gesamte SharePoint Farm oder nur innerhalb einer Site zu speichern. Wichtig ist, dass der verwendete Key für die jeweilige Ebene eindeutig sein muss. Die folgende Tabelle fasst die Möglichkeiten zusammen:

Ebene Zugriff
SPFarm Die Properties Eigenschaft der SPPersistedObject Klasse.
SPWebApplication Die Properties Eigenschaft welche von SPPersistedObject abgeleitet wurde.
SPSite Die AllProperties Eigenschaft des Root Web.
SPWeb Die AllProperties Eigenschaft.
SPList Die RootFolder.Properties Eigenschaft.

Beispiel

Als einfaches Beispiel erstellen wir nun ein neues WebPart mit jeweils einem Button zum Speichern und einem Button zum Laden eines Properties.

[ToolboxItemAttribute(false)]
public class WebPartPropertyBag : WebPart
{
private Button _buttonSave;
private Button _buttonLoad;
private TextBox _textBoxConnectionString;
 
const string _key = "DemoKey";
 
/// <summary>Der Schlüssel wird von SharePoint automatisch klein geschrieben</summary>
public string Key { get { return _key.ToLower(); } }
 
protected override void CreateChildControls()
{
_buttonSave = new Button
{
Text = "Save data!",
ID = "ButtonSave"
};
 
_buttonLoad = new Button
{
Text = "Load data!",
ID = "ButtonLoad"
};
 
_textBoxConnectionString = new TextBox();
 
_buttonSave.Click += PropertySpeichern;
_buttonLoad.Click += PropertyLaden;
 
Controls.Add(_buttonSave);
Controls.Add(_buttonLoad);
Controls.Add(_textBoxConnectionString);
}
}

Nun benötigen wir eine Methode zum Speichern des Wertes:

private void PropertySpeichern(object sender, EventArgs e)
{
var web = SPContext.Current.Web;
web.Properties.Add(Key, _textBoxConnectionString.Text);
// Update MUSS aufgerufen werden wenn eine Property hinzugefügt oder geändert wurde
web.Update();
web.Properties.Update();
 
_textBoxConnectionString.Text = string.Empty;
}

Und zum Abschluss noch eine Methode zum Laden des Wertes:

private void PropertyLaden(object sender, EventArgs e)
{
var web = SPContext.Current.Web;
_textBoxConnectionString.Text = web.Properties[Key] ?? "Property nicht gefunden :(";        
}

Mehr Code ist nicht notwendig um auf das PropertyBag zuzugreifen! Um die so gespeicherten Werte zu verwalten ist allerdings noch eine separate Oberfläche notwendig. Mit ein wenig Aufwand ist es so möglich eine gut integrierte Verwaltung für mehrere Applikationen zu schreiben.

Fazit

Die Flexibilität des PropertyBags ist sowohl ein Vor- als auch ein Nachteil. Zum einen ist es möglich von verschiedenen Applikationen aus das gleiche Property zu verwenden. Auf der anderen Seite muss man aber auch aufpassen, keine Properties von anderen Applikationen oder gar SharePoint zu überschreiben. Deshalb empfiehlt es sich immer einen Präfix wie den Namen des Features zu verwenden.

Zum Abschluss noch einmal die Vor- und Nachteile des Property Bags.

Vorteile

  • Scope

    Werte können granular auf verschiedenen Ebenen gespeichert werden.

  • Implementierung

    Gut geeignet wenn einfache key/value Paare gespeichert werden sollen. Wobei hier zwingend auf eine eindeutige Namenskonvention geachtet werden muss, sonst überschreiben Applikationen ungewollt die Werte anderer Applikationen.

Nachteile

  • Implementierung

    Nicht so gut geeignet wenn es darum geht komplexe Datentypen zu speichern. Es können nur serialisierbare Datentypen gespeichert werden und diese müssen dazu noch „von Hand“ serialisiert werden.

  • Administration

    Es gibt keine mitgelieferte Oberfläche zum Verwalten der Werte. Diese muss selbst erstellt werden.

  • Sicherheit Zum schreiben ist je nach Ebene ist eine andere Berechtigung erforderlich (SPWebApplication nur als Farm Administrator). Lesen kann hingegen jeder Benutzer.
  • Wartbarkeit

    Standardfeature von SharePoint. Es müssen keine zusätzlichen Komponenten installiert und nichts konfiguriert werden. Zusätzlich müssen die Properties auch nicht verwaltet werden. Wird die Site gelöscht, werden auch die dazugehörigen Properties gelöscht.

Ein interessanter Hinweis noch zum Schluss. Auf das PropertyBag kann auch aus dem SharePoint Designer heraus zugegriffen werden.

Zu finden unter Websiteoptionen im RibbonMenu:

201

202

Innerhalb dieser Auflistung werden alle aktuell genutzten PropertyBag-Key-Value-Paare angezeigt.