(0) exportieren Drucken
Alle erweitern
Dieser Artikel wurde maschinell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen.
Übersetzung
Original

Vergleich zwischen Apps für SharePoint und SharePoint-Lösungen

SharePoint 2013

In dieser Lektion lernen Sie, wann die Erweiterung SharePoint 2013 als ein App für SharePoint entwickeln und sie als ein SharePoint- Farmlösung oder eine codelose Sandkastenlösungentwickeln.

Letzte Änderung: Freitag, 10. Januar 2014

Dieser Artikel vergleicht die Anwendungsfälle des Apps für SharePoint, Farmlösungenund ohne Code- Sandkastenlösungen (NCSSs).

  • Neue Apps für SharePoint sind eigenständige Erweiterungen, die Cloud-basierte Logik und Daten, SharePoint Komponenten und von clientseitigen Skripts enthalten können, aber keine benutzerdefinierten verwalteten Code, der auf SharePoint Servern ausgeführt wird. Sie werden von der Office Store oder eine Organisation Anwendungskatalog installiert und können auf lokalen Farmen oder Microsoft SharePoint Onlineinstalliert werden. Einen Überblick über die Apps für SharePointfinden Sie unter Übersicht über Apps für SharePoint.

  • SharePointFarmlösungen sind die Pakete von SharePoint -Komponenten, die farmweite Galerie hochgeladen werden, von wo sie installiert werden können. Sie können nicht durch die Office Storeverteilt werden, und sie können nicht auf SharePoint Onlineinstalliert werden. Sie können benutzerdefinierten verwalteten Code enthalten, der auf den Farmservern SharePoint ausgeführt wird. Weitere Informationen über die Grundlagen des Farmlösungenfinden Sie unter Übersicht über Lösungen und Farmlösungen.

  • NCSSs sind auch Pakete SharePoint Komponenten. aber hochgeladen in den Katalog eine Websitesammlung aus, in dem sie installiert werden können. Um eine vor-Ort-Farmen oder SharePoint Onlineinstalliert werden, aber sie können nicht durch die Office Storeverteilt werden. Sie können die fast der gleichen Art beschreibenden Komponenten wie Apps für SharePoint und wie Anwendungen, können sie JavaScripthaben, aber sie enthalten keine benutzerdefinierten verwalteten Code, der auf dem SharePoint -Server läuft. Unterschiede in den Systemen der Bereitstellung von Anwendungen und NCSSs stellen NCSSs eine bessere Entwicklungsoption für eine kurze Liste der Szenarien. Informationen über Sandkastenlösungenfinden Sie unter Sandboxed Solutions in SharePoint 2010.

Wichtiger Hinweis Wichtig

Während der Entwicklung von Sandkastenlösungen , die nur deklarativen Markup und JavaScript – das wir ohne Code Sandbox-Lösungen (NCSS) bezeichnet – enthalten noch lebensfähig ist, haben wir die benutzerdefinierten verwalteten Code innerhalb der Sandkastenlösungnicht mehr verwendet. Wir haben das neue SharePoint app-Modell als Ersatz für diese Szenarien eingeführt, die die Verwendung von verwaltetem Code erforderlich. Das Modell app entkoppelt Kernprodukt SharePoint von der Runtime app, und dies ermöglicht eine größere Flexibilität und gibt Ihnen die Möglichkeit zum Ausführen des Codes in der Umgebung Ihrer Wahl. Uns ist bewusst, dass unsere Kunden Investitionen in codierten Sandkastenlösungen vorgenommenen und wir werden sie mit verantwortlich. Vorhandene codierten Sandkastenlösungen wird weiterhin in lokale SharePoint-Farmen auch in naher Zukunft arbeiten. Aufgrund der dynamischen Beschaffenheit von online-Diensten, bestimmen wir Support-Anforderungen für codierten Sandkastenlösungen in SharePoint Online auf der Grundlage von Kundenanforderungen. NCSSs werden weiterhin unterstützt. Machen das neue SharePoint app Modell breitere und leistungsstärkere werden alle Ihre zukünftige Investitionen gehen. Daher wird empfohlen, alle neuen Entwicklungen nach Möglichkeit das neue app-Modell verwenden soll. In Szenarien, in denen ein Farmlösung entwickeln oder Sandkastenlösungkodiert, empfehlen wir, dass Sie es so entwerfen, dass es leicht zu einer lose gekoppelten Entwicklungsmodell entwickeln kann.

Die wichtigsten Leitlinien können, die wir Sie geben, ist die Entwicklung einer App für SharePoint statt einer Farmlösung oder NCSS möglich. Apps für SharePoint haben die folgenden Vorteile gegenüber den klassischen Lösungen:

  • Bieten Sie Benutzern des einfachsten Prozess Discovery, Kauf und Installation.

  • Geben Sie Administratoren die sichersten SharePoint -Erweiterungen.

  • Bieten Ihnen die einfachste Marketing- und System basiert auf einer Microsoft online app Store.

  • Maximieren Sie Ihre Flexibilität bei der Entwicklung von zukünftigen Aktualisierungen.

  • Maximieren Sie Ihre Fähigkeit, Ihre vorhandenen nicht -SharePoint Programmierkenntnisse nutzen.

  • Cloud-basierte Ressourcen in glatter und flexiblere Möglichkeiten zu integrieren.

  • Aktivieren Sie eine Erweiterung, die Berechtigung haben, sich von den Berechtigungen des Benutzers, der die Anwendung ausführt.

  • Aktivieren Sie Cross-Plattform-Standards, einschließlich HTML, REST, OData, JavaScriptund OAuth verwenden.

  • Können Sie die Bibliothek SharePoint Domain-übergreifende JavaScript Zugriff auf SharePoint Daten nutzen. Auch können Sie verwenden eine Microsoft bereitgestellten Sicherheitstokendienst, das OAuth-kompatibel ist oder digitale Zertifikate Autorisierung an SharePoint Daten abrufen.

Apps für SharePoint und NCSSs verwenden Sie eine der SharePoint Client-Objektmodelle oder REST-Endpunkte auf SharePoint Inhalt und Komponenten zugreifen. Dieser Client APIs ermöglichen SharePoint -Erweiterungen, die für Endbenutzer entwickelt wurden. ("Endbenutzer" in diesem Kontext sind Administratoren der Websitesammlung, Website-Besitzer und Mitglieder der Website.) Das Server-Objektmodell verfügt über zusätzliche APIs zur Verfügung, mit denen Programmerweiterungen SharePoint Management, Konfiguration und Sicherheit. Dazu gehören Erweiterungen der Zentraladministration, benutzerdefinierte Windows PowerShell Befehle, Zeitgeberaufträge und benutzerdefinierte Backups. Weitere Informationen über die Arten von administrativen Erweiterungen, die Sie erstellen können, finden Sie unter SharePoint Foundation-Administration. Diese administrativen Erweiterungen werden in SharePoint Funktionen bereitgestellt, die Farm, Webanwendung und Websitesammlung Bereich haben. SharePointFarmlösungen werden auch durch Farmadministratoren installiert, obwohl vom Mieter und Websitesammlungsadministratoren apps und NCSSs installiert werden können.

Das Serverobjektmodell hat auch APIs für das Erstellen, lesen, aktualisieren und löschen böte auf Listen, Bibliotheken und Websites und für Vorgänge für andere Komponenten SharePoint . Dies bedeutet, dass das Server-Objektmodell kann verwendet werden, für Erweiterungen, die für Endbenutzer bestimmt sind, jedoch aus Gründen, die im vorherigen Abschnitt angegeben, Farmlösungen sind nicht in der Regel die beste Wahl für solche Erweiterungen. Daher ist es nicht verwunderlich, dass Farmlösungen nicht auf Microsoft SharePoint Onlineinstalliert werden. Da Microsoft das Management der SharePoint Onlinebehandelt, besteht keine Notwendigkeit, administrative Erweiterungen. Weitere Informationen über die unterschiedlichen Gruppen von APIs in der SharePoint und der Überlappung finden Sie unter Wählen Sie den richtigen API-Satz in SharePoint 2013.

Die Client-Objektmodellen und REST-Endpunkte duplizieren die administrative-orientierten APIs des Serverobjektmodells nicht. Da weder ein App für SharePoint noch ein NCSS benutzerdefinierten Code, der auf dem SharePoint -Server läuft enthält, können nicht sie darüber hinaus diese Administrations-APIs aufrufen. Darüber hinaus müssen alle Funktionen im Apps für SharePoint Bereich der Website; und Funktionen in NCSSs Websitesammlung oder Website-Bereich. Folglich kann eine Erweiterung administrative-orientierte SharePoint nicht wirklich mit einer App für SharePoint oder NCSS. Das zweite Prinzip, aber keine absolute Regel darum, dass Anwendungen und NCSSs für Endbenutzer und Farmlösungen sind für Administratoren gedacht.

Treten möglicherweise einen kleinen Anzahl SharePoint Entwicklungsszenarios für die app-Modell nicht geeignet ist, aber Sie mit einer Farmlösung , z. B. implementieren können, da die Lösung auf SharePoint Online sein muss oder durch ein Websitesammlungs-Administrator installiert werden muss. Es gibt zwei umfassende und überlappende Kategorien mit solchen Szenarios.

  • Branding:SharePoint Benutzer möchten häufig geben ihre SharePoint -Websites, einschließlich ihrer SharePoint Online -Websites, die ein benutzerdefiniertes Layout mit ihren eigenen Farben, Formatvorlagen, Layouts und Logos. Dies ist im Allgemeinen einfacher mit NCSSs als mit Apps für SharePointzu tun. Ein App für SharePoint hat die deklarative Steuerung der Darstellung von nur eigene Web app. Für das Web Server können sie nur Multifunktionsleisten-Schaltflächen und Menüelemente (und app Teile) deklarativ hinzufügen. Alle anderen Änderungen an eine Web-Host oder seine übergeordneten Websitesammlung, Miet- oder lokalenSharePoint Webanwendung muss mit Code oder Skripts, die eine der SharePointClient-Objektmodellen verwendet erfolgen. Z. B. muss neue Symbole oder CSS-Dateien programmgesteuert bereitgestellt werden. Dieser Code konnte von der Anwendung selbst ausgeführt werden, nachdem installiert ist, oder sie können im Ereignishandler app-Installation ausgeführt. Aber es würde viel Arbeit, um diesen Code zu erstellen. Darüber hinaus die app müssten auf Websitesammlungsebene Websiteberechtigungen auf Websites außerhalb seiner eigenen Webanwendung- und Host-Web ändern, und es müsste Mieter im Bereich Berechtigungen zum Ändern von mehr als nur der übergeordneten Websitesammlung. Ein branding NCSS hingegen kann bereitgestellt und werden für jede Websitesammlung aktiviert; und es kann aus nur wenigen rein deklarative Komponenten bestehen.

    Hinweis Hinweis

    Beachten Sie, dass SharePointFarmlösungen sind möglicherweise leistungsfähiger als NCSSs oder Apps für SharePoint für das branding, aber sie nicht auf SharePoint Online sind.

  • "Vorlage-Like" Erweiterungen: Angenommen Sie, Sie eine Erweiterung Krisenmanagement für SharePoint für die gemeinsame Analyse und Lösung von Business Krisen erstellt müssen. Die Erweiterung enthält verschiedene benutzerdefinierte Liste, ohne Code Workflows und andere Komponenten SharePoint , die in einem benutzerdefinierten WebTemplate kombiniert. Nehmen wir an, Sie verpacken und Bereitstellen die Erweiterung als eine NCSS. Nach der Aktivierung der Funktion in der Projektmappe können Benutzer bei jedem eine Krise auftreten ein Unterweb Krisen-Management ihrer SharePoint Website erstellen. Sie können die Website mit Daten auffüllen, die spezifisch auf die Krise ist. Auf der anderen Seite können Sie die Erweiterung App für SharePoint mit genau den gleichen Satz von Komponenten SharePoint implementieren. Bei der Installation der Anwendung auf der Teamwebsite wird sofort das Unterweb (als "app Web" bezeichnet) erstellt. Erneut, Hinzufügen von Benutzern die Website mit relevanten Daten.

    Jetzt, wenn eine zweite Krise occurs? passiert, wenn Sie die Erweiterung als ein NCSS implementiert, können die Benutzer nur anderen Unterwebs aus Ihren benutzerdefinierten WebTemplate erstellen. Wenn Sie die Erweiterung als ein App für SharePointimplementiert, haben die Benutzer jedoch ein Problem. Sie können keine zweite Instanz der Anwendung auf der übergeordneten Website installieren. Nur eine Instanz jeder App kann auf einem Web-Host installiert werden. Das beste, das was Sie tun können, ist eine Unterwebsite der übergeordneten Website dienen als Speicherort für eine andere Instanz der Anwendung zu installierenden erstellen. Bei der Installation der Anwendung wird ein neues Web von app, ist ein Sub-Unterweb der übergeordneten Website für die app-Komponenten erstellt. Dieser Vergleich zeigt eine allgemeine, jedoch kein absoluter Prinzip: SharePoint -Erweiterungen, die einen "Vorlage" Charakter – d. h., eine wieder verwendbare Sammlung von Komponenten, die für jeden bestimmten Anwendungsfall konfiguriert werden muss, aber natürlich haben mehrere Instanzen der gleichen SharePoint Website – besser mit dem NCSS Development-Modell als mit dem app-Modell passen. In diesem Beispiel Variable Element ist die Krise, aber es ist einfach, Erweiterungen des Vorlagen-ähnliche SharePoint vorstellen, in denen die Instanzen nach Region, Datum oder eine beliebige Anzahl anderer Eigenschaften variieren.

Informationen zum Erweitern der Möglichkeiten der Apps für SharePointfinden Sie unter Verwenden Sie konservativ app-Ereignishandler und Anwendungen, die Erstellen von Erweiterungen.

Wie bereits erwähnt, ist benutzerdefinierter Code, der auf dem SharePoint -Server läuft in Apps für SharePointnicht zulässig. Dies ist keine beträchtliche Einschränkung. Es bedeutet einfach, dass die benutzerdefinierte Geschäftslogik entweder "down" auf dem Client-Gerät oder "oben" in die Cloud verschoben wird. In beiden Fällen können Sie die SharePoint REST/OData service umSharePoint Zugriff auf Websites, Listen und anderen Daten verwenden. Sie können auch Remote SharePoint Daten über die SharePoint JavaScript, Silverlight, or .NET Framework client object modelszugreifen. Schließlich können Sie auf Windows Phone-s SharePoint über das SharePoint-Windows Phone -Objektmodell zugreifen. Weitere Informationen über die verschiedenen Gruppen von APIs in SharePoint 2013finden Sie unter Wählen Sie den richtigen API-Satz in SharePoint 2013.

Eine ähnliche Nummer ist kein Funktionen in Apps für SharePoint Websitesammlung, Webanwendung oder Farm Bereich haben. Allerdings müssen Sie alle Elemente der Benutzeroberfläche (UI) oder Funktionen aufgeben. Es bedeutet, dass die Implementierung der Komponente ausSharePoint und auf einen Client oder remote Web-Anwendung oder entfernten Datenbank verschoben wird.

In der folgende Tabelle enthält die SharePoint -Komponenten, die nicht in einem App für SharePointbereitgestellt werden, und beschreibt die "app wie" die gleiche Funktionalität zu erhalten.

Wenn Sie möchten, dass die Funktionalität von...

... diese Ansätze versuchen.

Benutzerdefinierte Webparts

Ein App für SharePoint kann remote Seiten haben, die benutzerdefinierte Webparts enthalten. Eine andere Möglichkeit ist, eine Seite aus einer remote-Webanwendung in einem app-Webpart auf der Seite einer SharePoint Website verfügbar zu machen. Die remote-Seite haben im Wesentlichen die gleichen Steuerelemente der Benutzeroberfläche und Funktionen als Webpart. Weitere Informationen finden Sie unter Gewusst wie: Erstellen von App-Webparts zur Installation mit Ihren Apps für SharePoint.

Ereignisempfänger und Funktionsempfängern

Ein App für SharePoint kann mit entsprechenden remote-Ereignisempfänger enthalten. Weitere Informationen finden Sie unter Behandeln von Ereignissen in Apps für SharePoint.

Benutzerdefinierte Feldtypen (Spalte)

Eine Anwendung kann ein neues Feld (Spalte) bereitstellen, das auf einer der existing field typesbasiert. Die Feldtypen, Calculated und Computed sind besonders flexibel. Eine weitere Option ist, Ihre Daten auf einer remote-Webseite zu präsentieren, benutzerdefinierte Steuerelemente oder Raster mit.

Benutzerdefinierte Webdienste auf der SharePoint- Service Application Framework

Sie können Ihre benutzerdefinierte Webdienste als remote Services entwickeln.

Anwendungsseiten

Ein App für SharePoint kann remote-Webseiten enthalten, die von jeder Website verfügbar sind, auf denen die Anwendung installiert ist. Eine app auch können integrierte SharePoint Webparts auf Seiten der Website.

Alle unten aufgeführten SharePoint Komponenten werden im Endbenutzer-Szenarien verwendet, aber haben keine Entsprechungen in der app-Modell SharePoint und können in NCSSs bereitgestellt werden. Dafür müssen Sie Farmlösungenverwenden.

Verwenden Sie konservativ app-Ereignishandler

Sie können einige der Einschränkungen des Apps für SharePoint überwinden, durch Erstellen von Handlern für die installierten Anwendung, app aktualisiert und Deinstallieren von app-Ereignisse. Diese Handler sind Webdienste, die auf Webservern außerhalb der Farm SharePoint möglicherweise in der Cloud gehostet werden. SharePoint Client-Objektmodell oder den REST-APIs können sie auf SharePoint -Komponenten, einschließlich der Komponenten im Web Host CRUD-Operationen durchzuführen. In der Theorie können Sie diese Handler einige Einschränkungen der Bereitstellung in der Branding und Erweiterungen des Vorlagen-ähnliche Elemente, die weiter oben erläuterten zu überwinden. Allerdings empfiehlt es sich, diese Handler nur als letzten Ausweg verwenden, wenn es keine andere Möglichkeit gibt, den Kunden die Funktionalität bieten, die Ihre Anwendungsfall erforderlich sind. Bei der Entscheidung, ob einen Handler erstellen, beachten Folgendes:

  • Programmatische Bereitstellung im Web Server erfordert, dass die Anwendung Vollzugriff auf das Web Host anfordern. Anwendungen, die diese Berechtigung erfordern, nicht durch die Office Storeverkauft werden.

  • Bereitstellung der Komponenten im Web Host tendenziell die Sicherheitsvorteile der Umsetzung von SharePoint Komponenten in einem Web app mit seiner eigenen Domäne beeinträchtigen.

  • Umfangreiche Bereitstellungscode ist eine Menge Arbeit erstellen und Debuggen mit dem Markup beschreibenden Bereitstellung verglichen, die für app-Webkomponenten und in NCSSs verwendet werden können.

  • Es gibt einige wichtigen Empfehlungen, die bei der Erstellung von app-Ereignishandler befolgt werden müssen. Der Code umfaßt Rollbacklogik um alles rückgängig zu machen, was sie getan hat, wenn ein Fehler auftritt. Damit die Infrastruktur Alles zurücksetzen können, die es getan hat muss auch die SharePoint Infrastruktur des Fehlers benachrichtigt.

  • App-Ereignishandler sind nicht möglich, mit dem Typ des App für SharePoint als SharePoint-gehostet.

Weitere Informationen zu app-Ereignishandlern finden Sie unter den SDK-Knoten Behandeln von Ereignissen in Apps für SharePoint. Finden Sie Informationen über die Rollbacklogik http://msdn.microsoft.com/de-de/library/dn265919#AddRollbackLogic das zuletzt genannte Thema wird im Kontext der Anwendung aktualisierte Ereignis geschrieben, aber die grundlegenden Prinzipien gelten für alle app-Ereignishandler.

Anwendungen, die Erstellen von Erweiterungen

Alternativ können Sie das Clientobjektmodell SharePoint -- oder die REST-APIs verwenden, um die Komponente Bereitstellungsprobleme mit Apps für SharePoint, lösen soll CRUD-Code in der Anwendung selbst, sondern in einem app-Ereignishandler haben. Die Anwendung wird dann eine Art von Factory für eine benutzerdefinierte Erweiterung. Z. B. konnte eine Von SharePoint gehostete App das SharePointJavaScript -Objektmodell verwenden, Bereitstellung und andere CRUD-Operationen im Web Host oder an einer anderen Stelle in der Miet- oder Web-Anwendung ausführen. Ein weiteres Beispiel finden Sie die kurze Einführung in die remote-Bereitstellung Abschnitt Techniken und remote-Bereitstellung von SharePoint 2013 Siteeinstellungen für die Bereitstellung, die beschreibt, wie eine gehostete Anbieter App für SharePoint verwendet wird, um zu ermöglichen, das Unterweb viel wie SharePointprovisioning in-the-Box ist Unterweb Bereitstellung. Es gibt jedoch viele Rad-Neuerfindung und damit einen Großteil der Arbeit bei der Erstellung einer Factory- App für SharePoint. Diese Art von app kann nicht zusätzlich durch die Office Store verkauft werden, weil die Anwendung Vollzugriff auf das Web Server benötigt.

Anzeigen:
© 2014 Microsoft