Drei Methoden für Entwurfsoptionen für SharePoint-Add-Ins

  • Artikel

Voraussetzung: Sie sollten sich zunächst mit dem Artikel SharePoint-Add-Ins vertraut machen.

Dieser Artikel behandelt drei architekturbezogene Auswahlmöglichkeiten für SharePoint-Add-Ins unter drei Aspekten. Zunächst lernen Sie die wichtigsten Kategorien der Entwurfsentscheidungen kennen. Anschließend wird die Add-In-Architektur im Hinblick auf Anwendungsebenen betrachtet. Und schließlich werden Faktoren beleuchtet, die Sie bei Ihren Entwurfsentscheidungen berücksichtigen sollten.

Die erste Entscheidung, die Sie treffen müssen, ist, ob die SharePoint-Erweiterung ein SharePoint-Add-In oder eine klassische SharePoint-Farmlösung oder Sandkastenlösung sein soll. Einige Teile des SharePoint-Objektmodells, vor allem in Verbindung mit der Anpassung der SharePoint-Verwaltung und -Sicherheit, sind für Clients nicht zugänglich. Auf diese Teile kann nur von auf dem SharePoint-Server ausgeführtem benutzerdefinierten Code zugegriffen werden. Benutzerdefinierter serverseitiger Code ist in einem SharePoint-Add-In nicht zulässig. (Über einen umfangreichen Satz von Clientobjektmodellen und einen REST/OData-Dienst können SharePoint-Add-Ins nahezu jede endbenutzerorientierte SharePoint-Erweiterung ausführen.)

Weitere Informationen zur Entscheidung zwischen klassischen Lösungen und Add-Ins finden Sie unter SharePoint-Add-Ins im Vergleich zu SharePoint-Lösungen. Ebenfalls hilfreich für diese Entscheidung ist der Artikel Auswählen des richtigen API-Satzes in SharePoint.

Schlüsselelemente beim Entwurf von SharePoint-Add-Ins

Beim Entwerfen eines SharePoint-Add-Ins sind im Wesentlichen drei Kategorien von Entscheidungen zu fällen. Wie immer sind beim Anwendungsentwurf bestimmte Abwägungen zu treffen. Entscheidungen in einer Kategorie können die Optionen in einer anderen beeinflussen. Nicht jede mögliche Kombination von Entscheidungen ist umsetzbar.

  • Hosting: SharePoint-Add-Ins können bezüglich ihrer Bereitstellung und ihres Hostings in zwei Haupttypen unterschieden werden.

    • Bei vom Anbieter gehosteten Add-Ins wird primärer Datenspeicher und die Geschäftslogik von Ihnen als Entwickler außerhalb von SharePoint auf Servern oder in einem Cloudkonto bereitgestellt und gehostet. Sie sind für das Erzwingen der Isolation zwischen den Konten verschiedener Kunden verantwortlich, die das Add-In erwerben. Diese Add-Ins können auch SharePoint-Komponenten enthalten. Diese werden in der SharePoint-Farm des Kunden gehostet. Diese Art von Add-Ins bietet Ihnen die größte Flexibilität in den übrigen Kategorien von Designentscheidungen. Sie können auch Nicht-Microsoft-Plattformen für externe Daten, Logik und die Webbenutzeroberfläche verwenden. (Innerhalb der Kategorie der vom Anbieter gehosteten Add-Ins müssen Sie auch zwischen Add-Ins unterscheiden, deren Remotekomponenten sich innerhalb derselben Unternehmensfirewall wie die SharePoint-Farm befinden, und solchen, deren Remotekomponenten sich außerhalb dieser Firewall befinden. Die Autorisierungssysteme für diese beiden Szenarien sind unterschiedlich, was wiederum einen Unterschied macht, in welcher Programmiersprache Sie für den Zugriff auf die SharePoint-Daten verwenden.)

    • Von SharePoint gehostete Add-Ins bestehen vollständig aus SharePoint-Komponenten wie Listen, Inhaltstypen, Workflows und Webparts. Es gibt keine externen Komponenten. Weitere Informationen zu den Arten von SharePoint-Komponenten, die in SharePoint-Add-Ins enthalten sein können, finden Sie unter Hostwebsites, Add-In-Websites und SharePoint-Komponenten in SharePoint.

    Ausführlichere Informationen zu den Hostingoptionen von SharePoint-Add-Ins finden Sie unter Auswählen von Mustern für die Entwicklung und das Hosting Ihres SharePoint-Add-Ins.

  • Konnektivität: In SharePoint werden drei Arten von sicherem Zugriff zum Erstellen/Lesen/Aktualisieren/Löschen (Create/Read/Update/Delete, CRUD) auf Daten unterstützt.

    Weitere Informationen zu Datenspeicherung und -zugriff in SharePoint-Add-Ins finden Sie unter Datenspeicher in Add-Ins für SharePoint, Sicherer Datenzugriff und Clientobjektmodelle für SharePoint-Add-Ins und Arbeiten mit externen Daten in SharePoint.

  • BENUTZEROBERFLÄCHE: Es gibt drei Möglichkeiten, ein SharePoint-Add-In in SharePoint anzuzeigen: Mindestens alle Add-Ins werden auf einer vollständigen Webseite angezeigt. Optional kann ein Add-In auch durch ein Add-In-Webpart und durch ein Menüelement oder eine Menübandschaltfläche dargestellt werden. Weitere Informationen finden Sie unter UX-Design für SharePoint-Add-Ins.

Hinweis

SharePoint-Add-Ins können von den Kunden in mehreren Websitesammlungen eines Mandanten oder auf einzelnen Websites installiert werden. Erstere werden als Add-Ins mit Mandantenbereich bezeichnet. Wenn Sie den Kunden die Option des Mandantenbereichs bieten möchten, können Sie keine benutzerdefinierte Menübandschaltfläche und kein Add-In-Webpart einschließen. Weitere Informationen finden Sie unter Mandantschaften und Bereitstellungsbereiche von SharePoint-Add-Ins

Architekturebenen

Eine weitere Möglichkeit, sich die Optionen ihrer Add-In-Architektur zu überlegen, besteht darin, dass das Add-In drei logische Ebenen umfasst: die Benutzeroberfläche, die Geschäftslogik und den Datenzugriff. Jede Ebene verfügt über mehrere Implementierungsoptionen. auch hier schränken die Für eine Ebene getroffenen Optionen die Optionen für andere ein. In den folgenden Tabellen werden einige der Optionen und deren Verwendungsmöglichkeiten für die Remotekomponenten eines Add-Ins und die SharePoint-Komponenten beschrieben.

Remotekomponenten in vom Anbieter gehosteten Add-Ins: Optionen für die einzelnen Ebenen

Ebene Optionen Vorteil
Benutzeroberfläche ASP.NET-Seiten in einem ASP.NET-Formular oder einer MVC-Anwendung, gehostet in einer Azure-Webrolle. Nutzen der Erfahrung von ASP.NET-Entwicklungsmitarbeitern
HTML 5-Seite mit JavaScript Umfangreiche Benutzeroberfläche
PHP- oder andere Webseite, gehostet in einem nicht von Microsoft bereitgestellten Clouddienst Integrieren von nicht von Microsoft stammenden Anwendungen in SharePoint
Silverlight in einer Windows Phone-App Mobiler Zugriff auf SharePoint-Daten und Integration mit Geolocation-Daten und Push-Benachrichtigungen
Geschäftslogik Clientseitiges JavaScript Benutzeroberflächenlogik und einfache Geschäftslogik; Zugriff auf SharePoint-Daten über das JavaScript-Clientobjektmodell
Eine Microsoft Azure-Workerrolle Prozessorintensive Funktionalität. Zugriff auf SharePoint-Daten über das .NET Framework-Clientobjektmodell.
Ein Remotewebdienst Prozessorintensive Funktionalität. Zugriff auf SharePoint-Daten über das .NET Framework-Clientobjektmodell.
Daten SQL Azure Relationale Daten mit vollem Funktionsumfang
Azure-Tabellenspeicher Anwendungseinstellungen und andere Metadaten
Azure Blob Storage Speicherung großer Dateien
Ein nicht-Microsoft-Clouddienst Nutzen vorhandener Datenquellen auf Basis nicht von Microsoft stammender Plattformen
Eine Datenbank auf dem eigenen Server des Entwicklers Hosting durch den Anbieter und Kontrolle der Mandantenisolation durch den Entwickler

SharePoint-Komponenten: Optionen für die einzelnen Ebenen

Ebene Optionen Vorteil
Benutzeroberfläche Benutzerdefinierte Ansichten von Listen und Bibliotheken von SharePoint auf Add-In-Webseiten Optimale Integration in die Darstellung und das Verhalten von SharePoint
Silverlight-Anwendung, die in einem Webpart (oder in <Objekttags> ) auf einer Add-In-Webseite gehostet wird Nutzen vorhandener Erfahrungen bei der Silverlight-Entwicklung; Umfassende Benutzeroberfläche
Geschäftslogik Ein SharePoint-Workflow Implementieren von Geschäftsprozessen
Clientseitiges JavaScript, ergänzt durch die domänenübergreifende SharePoint-Bibliothek Zugriff auf SharePoint-Daten im Add-In-Web; Zugriff auf Daten auf anderen Websites des Mandanten
Ein Remoteereignishandler Behandeln von CRUD-Ereignissen in SharePoint-Listen und Bibliotheken mit extern gehosteter Logik
Daten Listen und Bibliotheken von SharePoint, die über Collaborative Application Markup Language (CAML)- oder LINQ-Abfragen mit einem der SharePoint-Clientobjektmodelle abgefragt werden Nutzen vorhandener Erfahrungen bei der SharePoint- und .NET Framework-Entwicklung
Listen und Bibliotheken von SharePoint, die über den SharePoint REST/OData-Webdienst abgefragt werden Zugriff auf SharePoint-Daten von nicht von Microsoft stammenden Plattformen; Nutzen vorhandener Erfahrungen mit OData-Abfragen
Ein BCS-Modell Darstellung externer Daten in SharePoint als SharePoint-Liste

Bei Entwurfsentscheidungen zu berücksichtigende Faktoren

Das SharePoint-Add-In-Modell bietet so viele Entwurfsmöglichkeiten, dass sich keine einfache Entscheidungsstruktur dafür erstellen lässt. Im Folgenden sind einige der wichtigsten Faktoren aufgeführt, die bei der Erwägung der Architektur einer SharePoint-Add-In zu berücksichtigen sind.

  • Der wichtigste Faktor ist die Funktionalität, die Sie den Kunden zur Verfügung stellen möchten, d. h. die Anwendungsfälle. Enthält Ihr Add-In beispielsweise prozessorintensive Funktionen, wie z. B. die Konvertierung von Videodateien in ein anderes Videoformat, spricht dies für ein vom Anbieter gehostetes Add-In, bei dem die Verarbeitung auf einem Ihrer Server oder in einer Azure-Workerrolle erfolgt.

  • Da bei einer Art von SharePoint-Add-In (vom Anbieter gehostete Add-Ins) Sie (oder Ihr Kunde) die Nicht-SharePoint-Komponenten hosten und die Mandantenisolation erzwingen müssen, sollten Sie bedenken, ob Sie (bzw. die Zielkunden) über die entsprechende Hardware und das erforderliche IT-Personal verfügen.

  • Welche Kunden Sie anzielen, ist ebenfalls ein wichtiger Aspekt. Wenn alle Ihre Add-Ins intern verwendet werden (d. h., Sie haben keine externen Kunden) oder von einem einzelnen Kunden verwendet werden, sind vom Anbieter gehostete Add-Ins erheblich einfacher zu implementieren und zu verwalten, als wenn Sie externe Kunden haben oder mehrere Kunden das Add-In verwenden. Wenn Sie beabsichtigen, das Add-In öffentlich zu verkaufen, sollten Sie auch überlegen, ob Sie es an Unternehmen mit SharePoint Online-Konten oder an Solche mit eigenen SharePoint-Farmen oder beides vermarkten.

  • Sie sollten auch Ihre vorhandenen Fähigkeiten oder die Fähigkeiten Ihrer Entwicklungsmitarbeiter berücksichtigen. Wenn Sie beispielsweise ein erfahrener ASP.NET Entwickler sind, wäre dies ein Vorteil für das Erstellen einer Remotewebanwendung und das Anzeigen von SharePoint-Listendaten auf einer ASP.NET Seite. Auf der anderen Seite, wenn Sie ein erfahrener SharePoint-Entwickler sind, wäre dies ein Punkt zugunsten der Verwendung einer benutzerdefinierten SharePoint-Liste und Websiteseite mit JavaScript für die Verarbeitung.

Siehe auch