(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

Entscheiden zwischen apps für SharePoint und SharePoint-Lösungen (Artikel)

SharePoint 2013

Die wichtigsten Überlegungen zu verstehen, wenn Sie, ob ein App für SharePoint oder einer voll vertrauenswürdigen SharePoint-Lösung erstellt treffen.

SharePoint 2013 ist eine neue Möglichkeit zum Anpassen von SharePoint mit apps eingeführt. Diese neuen hell-Note, SharePoint-als-a-Service und Oberfläche Ansatz können Sie zum Erstellen von SharePoint Anpassungen, die mit dem SharePoint integriert werden ohne die Auswirkungen auftreten, die SharePoint-Lösungen voll vertrauenswürdige Code auf die Lebenszyklus und Verwaltung von SharePoint-Umgebung haben können.

Die folgende Abbildung zeigt, wie eine app Ausführung von einer typischen SharePoint-Lösung unterscheidet.

Abbildung 1. Ausführung von Pfaden der apps für SharePoint und SharePoint-Lösungen

Diese Darstellung zeigt, wie sich die Ausführung einer App von der einer typischen SharePoint-Lösung unterscheidet.

In einer typischen SharePoint-Lösung führt auf der linken Seite des Bilds, siehe den Code in der SharePoint-Ausführung-Umgebung. Dies bedeutet, dass Ihre benutzerdefinierte Code negative Auswirkungen auf die SharePoint-Umgebung konnte. Im Falle von Apps für SharePoint, rechts führt den Code in einer Umgebung vollständig getrennt, ob sie im Browser oder in einer separaten Webanwendung hosten Umgebung ist. Diese Umgebung kommt überall Ihrer Wahl solange es die Generierung von Webseiten (d. h., auf einem Webserver) unterstützt.

App Formen

SharePoint 2013 können mehrere Möglichkeiten zur Interaktion mit und apps zugreifen. Die wichtige-Methode verwendet, um zu bestimmen, wie Ihre app mit interagiert werden ist die app-Shapes eine oder mehrere definieren. App-Formen bestimmen die Benutzerfreundlichkeit für die Interaktion mit und mithilfe einer Webanwendung. Derzeit gibt es drei app Formen zur Verfügung:

Immersive (oder Full-Seite app): Dieses Shape bietet eine voll fesselnde Funktionalität mithilfe der gesamten Seite. Während Sie das vollständige Kontrolle über die app-Erfahrung gibt, ist es wichtig, um sicherzustellen, dass Ihre app ordnungsgemäß wieder auf der SharePoint-Website verknüpft, sodass die Benutzererfahrung integrierte und nicht verloren ist. Um dies einfach, wir ein Chrom-Steuerelement, das können nicht nur Ihre app, zeigen einen Benutzer automatisch auf ihre SharePoint-Umgebung POST, sondern bietet Ihrer Webanwendung mit der aktuellen SharePoint cascading Stylesheet (CSS). Damit bei SharePoint seine CSS, beispielsweise über eine Änderung Theming, ändert Ihre app seine aussehen und Verhalten sowie geändert wird.

App-Webpart: Ein app-Webparts ist ein IFrame gehostet in einem Webpart, das von der Klasse ClientWebPart dargestellt wird. Der IFrame kann Parameter nehmen, die die Benutzeroberfläche der app-Webpart ändern können. Sie können diese app Erfahrungen als standard-Webparts, ähnlich vorstellen tun der Unterschied ist, dass sie nicht auf die gleiche Weise interagieren Vorversion Webparts.

Erweiterung app: Erweiterung apps sind nur benutzerdefinierte Aktionen, die zu einer Seite in Ihrer Anwendung weiterleiten können. Hierfür könnte eine Seite auf SharePoint, oder, im Fall einer Wolke gehosteter app, Remote gehosteten Webseite gehostet sein. Sie können Erweiterung apps als Eingangs-Punkte zu Ihrer app vorstellen. Sie bieten keine Benutzererfahrung in selbst.

Hosting-Optionen

Hosten von Anwendungen ist nicht so einfach wie das Hosten von SharePoint-Lösungen. Mit einer SharePoint-Lösung werden die hosting-Optionen ganz klar: Es wird auf einer SharePoint-Server gehostet und in der Domäne der SharePoint-Anwendung ausgeführt wird. Während dieser Auswahl ganz leicht vornimmt, Ausführen von benutzerdefiniertem Code innerhalb der Anwendungsdomäne von SharePoint viel Risiko zu einer SharePoint-Umgebung darstellt, und müssen Sie alles aus Anwendungslebenszyklus Anpassungen an der Upgrade Lebenszyklus von einer SharePoint-Umgebung verwalten. Apps können Sie die Anpassung unabhängig von der SharePoint-Umgebung zu verwalten, da sie SharePoint als Dienst und Portal im Gegensatz zur Ausführung in SharePoint verwenden. Hierzu müssen Sie bestimmen, wie Sie Ihre APP hosten möchten Hosting wird bestimmt basierend auf den Anforderungen Ihrer Anwendung.

Es gibt zwei grundlegende hosting Strategien für SharePoint: Wolke gehostete Anwendungen und SharePoint-gehostete Anwendungen.

Cloud gehostete Anwendungen: Apps cloudhosting sind Anwendungen, die werden Remote aus SharePoint gehostet und können eine Art von serverseitigen Logik enthalten. Sie können auf allen Plattformen Ihrer Wahl gehostet werden, ob es Microsoft Azure, (Internet Information Services, IIS) oder sogar einen PHP Server unter Linux ist.

Es stehen zwei wichtigste Arten der Cloud gehostete Anwendungen: die erste ist ein-Anbieter gehosteten app. Bestimmt im-Anbieter-gehostete Anwendungen der Entwickler der app, in dem die Anwendung gehostet wird. Die andere Art ist eine Autohosted-app. Diese hosting Option, die derzeit nur auf Office 365ist, nimmt die Komponenten, die Entwickler für die app erstellt und bereitgestellt, für die sie bei der Installation zu einer speziellen Windows Azure-Website und/oder der Datenbank, die vorgesehen ist für die SharePoint-Instanz. Auf diese Weise können Entwickler Anwendungen entwickeln, ohne zu bestimmen, wo Sie die app ausrichten.

SharePoint-gehostete Anwendungen: SharePoint-gehostete Anwendungen müssen nicht enthalten nur deklarative Inhalte wie HTML und JavaScript, und alle serverseitigem Code, die mit ihnen gepackt ist. Diese Arten von apps Speichern der HTML-Code und anderen Inhalten in SharePoint, und legen Sie einfach die deklarative Inhalte an den Browser. SharePoint-gehostete Anwendungen interagieren mit SharePoint über das JavaScript-Objektmodell oder Representational State Transfer (REST)-Endgeräte und werden mithilfe der clientseitigen basiert. Ähneln Entwurf und Interaktion der folgenden Arten von Anwendungen mithilfe der clientseitigen Entwurfsmuster-protokollierungsskripts für sandkastenlösungen verwendet.

Es sollte hingewiesen, dass SharePoint-gehostete Anwendungen auf deklarative Inhalte beschränkt sind und können keine serverseitigen Code enthalten. Allerdings werden cloudhosting apps nicht beschränkt auf nur Remote Inhalt gehostet. Cloudhosting apps können auch deklarative Inhalt enthalten, die Sie in SharePoint wie Webseiten, CSS, Inhaltstypen und So weiter gehostet wird.

App-Vertrauensstellung und Berechtigungen

Mit den voll vertrauenswürdige Lösungen hatte Code immer dieselben Berechtigungen wie für die SharePoint-Umgebung. Obwohl dies großen macht enthält, muss dieser ebenfalls sehr viel Diagnose und Beschränkung, da Sie Code schreiben können, die die SharePoint-Umgebung beeinträchtigen könnten. Einige Beispiele für Methoden, die Sie in der SharePoint-Entwicklung mit voller Vertrauenswürdigkeit Code achten haben werden:

  • Instanziieren eines SPSite -Objekts in einem Ereignisempfänger an.

  • SPList.Items oder SPFolder.Filesauflisten.

  • Löschen mehrerer Versionen eines Listenelements.

  • Verwenden von unbegrenzt SPQuery -Objekten.

  • Bei der umfassenden Verwendung von SPSite und SPWeb.

  • Erinnerung der SharePoint-Objekte entfernt immer an.

  • Vor unbeabsichtigten Änderungen der Signatur-Webpart.

Sandkastenlösungen geholfen, die verhindern, aber hatten sie auch ihre eigenen Einschränkungen.

Da apps außerhalb des Kontexts der SharePoint-Ausführung ausgeführt werden soll, müssen es eine Möglichkeit der vertrauenden ihnen, sicherzustellen, dass eine Anwendung kann nur was sie tun soll sein.

Hohe vertrauenswürdige Anwendungen

Eine hohe vertrauenswürdige Anwendung ist ein-Anbieter gehostete Anwendung für SharePoint für die Verwendung lokaler, die das Protokoll Servern (S2S) verwendet. "Hoher Vertrauenswürdigkeit" ist nicht identisch mit "Full-Trust", und hoher Vertrauenswürdigkeit bedeutet nicht, dass die Dienstanwendung voll vertrauenswürdig ist. Eine hohe vertrauenswürdige Anwendung muss weiterhin Berechtigungen anfordern. Die Anwendung ist "hoher Vertrauenswürdigkeit" betrachtet, weil es ist vertrauenswürdig aus, um eine beliebige Benutzeridentität verwendet werden, die die Anwendung erforderlich; die Anwendung ist verantwortlich für die Erstellung des Benutzer-Teils des Zugriffstokens.

Eine Anwendung hoher Vertrauenswürdigkeit wird für die Verwendung in einer lokalen Umgebung erstellt. Es dient nicht in Office 365ausgeführt wird. Anwendungen, die die Verwendung des Server-zu-Server-Protokolls wurden in der Regel hinter der Firewall in Instanzen installiert werden, die für jedes einzelne Unternehmen spezifisch sind.

Eine hohe vertrauenswürdige Anwendung ist ein-Anbieter gehostete Anwendung einer lokalen-Installation von SharePoint. Eine hohe vertrauenswürdige Anwendung verwendet das Zertifikat zum Einrichten einer Vertrauensstellung statt eine Kontexttoken. In SharePoint 2013bietet der SPTrustedSecurityTokenIssuer Zugriffstoken für Server-zu-Server-Authentifizierung.

Wenig vertrauenswürdigen Anwendungen und app-Berechtigungen

Wenig vertrauenswürdige Anwendungen sind die, die eine Broker Vertrauensstellung wie Microsoft Azure Access Services (Control ACS), verwenden, um als ein tokenherausgeber zwischen den SharePoint- und die Anwendung zu fungieren. Microsoft Azure Dienste der Zugriff ist natürlich ein Abonnement Office 365 ist.

SharePoint fordert ein Kontexttoken von ACS, das dann an den Speicherort die Anwendung hostet gesendet. Die Anwendung wird dann extrahieren Sie das Refresh-Token mithilfe des Tokens Kontext und ein Zugriffstoken von ACS angefordert werden mithilfe des Tokens aktualisieren. Wenn das Zugriffstoken eingeht, wird es wieder mit SharePoint reden von der Anwendung verwendet.

SharePoint wenig vertrauenswürdigen Anwendungen stützen sich auf den OAuth Autorisierung Codefluss ("erteilen Type") begrenzt Rechte an Anwendungen, die als Benutzer fungieren delegieren. Damit dies funktioniert müssen SharePoint und die Clientanwendung (die SharePoint-Webanwendung) als vertrauenswürdig und kommunizieren mit einem tokenherausgeber. SharePoint nutzt Microsoft Azure Active Directory (AD). Microsoft Azure AD, muss wiederum, SharePoint und die Clientanwendung, um ihnen die erforderlichen Token gewähren, für die Zusammenarbeit beachten.

Wenig vertrauenswürdigen Anwendungen können nicht mit Inhalten außerhalb der Web app interagieren, die sich die SharePoint-Webanwendung Sub handelt, die Ihre app Standardmäßig enthält. Zu diesem Zweck müssen Sie Berechtigungen für das Web Host angeben. Das Web-Host ist die SharePoint-Webanwendung, die im Web app für die app hostet. Diese angefordert Berechtigungen dann zugelassen oder verweigert werden durch das Installationsprogramm der app während der Installation. Das Verweigern der Berechtigungen (die nicht die app Vertrauen ist,) hindert die app zu installieren.

Ihre Entscheidung zu eine app im Vergleich zu einer SharePoint-Lösung erstellen von zwei Dinge festgelegt werden: zuerst, geben Sie die Funktionen der einzelnen Anpassung und Sekunde, die tatsächlichen Szenario Sie versuchen zu lösen. Nehmen wir einen Blick und vergleichen apps für SharePoint im Vergleich zu SharePoint-Lösungen. In diesem Abschnitt Schwerpunkt vollständig vertrauenswürdigen Code (SharePoint-Lösungen) anstelle von teilweise vertrauenswürdigem Code (sandkastenlösungen) auf. Nach SharePoint 2013ist teilweise vertrauenswürdigen-Benutzercode veraltet. Wenn Sie sich teilweise vertrauenswürdigen Code suchen, sollten Sie erwägen, eine Anwendung stattdessen schreiben.

Serverobjektmodell vs.-clientobjektmodell

Schreiben von SharePoint-Lösungen mussten Sie das SharePoint Server-Objektmodell verwenden. Dieses Objektmodell bietet eine sehr alle benötigten Informationen des Zugriffs auf SharePoint-Inhalte und der SharePoint-Umgebung. Der Nachteil dieses Objektmodell ist es erforderlich ist sehr viel Pflege, da der Code im Kontext von SharePoint ausgeführt wird, und haben Sie einen Fehler oder einige andere Leistungsproblem mit Code, und es konnte, und in der Regel würde, beeinträchtigt die SharePoint-Umgebung.

Das SharePoint-clientobjektmodell, protokollierungsskripts für sandkastenlösungen beliebte vorgenommen und jetzt deutlich verbessert für Apps für SharePoint, enthält APIs, die Remote her und interagieren mit SharePoint. Die hier ist darauf zurückzuführen, dass Ihr Code direkt auf die SharePoint-Umgebung auswirken kann nicht. Wenn Ihr Code nicht oder Leistungsprobleme hat, wirkt sich dies nicht vor potenziell nur Ihre app und die gesamte SharePoint-Umgebung.

Die folgende Tabelle zeigt die Stärken und Funktionen von Das Serverobjektmodell (SSOM) und clientobjektmodell (CSOM).

SSOM vs. CSOM

Szenarien

SSOM

CSOM

Administration

Yes

Nein

Inhaltsverwaltung

Yes

Yes

Websiteverwaltung

Yes

Yes

Das Websitebranding

Yes

Nein

Synchrone Ausführung

Yes

Yes

Asynchrone Ausführung

Nein

Yes

Anforderungen im Batchmodus

Nein

Yes

Veraltet APIs

Mit der Einführung von der Cloud-App-Objektmodell und die neue REST-Endpunkte (/_api/) sind einige bereits vorhandene Dienstendpunkte nun veraltet. Diese veraltet APIs gehören die folgenden Webdienste:

  • Listdata.svc

  • ASMX-Webdienste

Code, die derzeit diese veraltet Webdienst-Endpunkte verwendet sollte umgestaltet werden, um die entsprechende REST-Endpunkt (/_api/) oder der Client-Side Object Model verwenden.

Umgebung

Die Umgebung, in dem Sie SharePoint ausführen, ist ein entscheidender entscheidenden Faktor. Wenn die SharePoint-Umgebung Office 365ist, müssen Sie mithilfe des Cloud-App-Objektmodells und entwickeln alle Anpassungen als apps für SharePoint. Wenn die SharePoint-Umgebung lokales Postfach ist, können Sie die Wahl der apps oder voll vertrauenswürdige Lösungen. Denken Sie daran, wenn Sie möchten die Flexibilität, unterstützt sowohl lokale und cloud-Umgebungen, und klicken Sie dann möchten Ihre Lösung als app zu schreiben, da voll vertrauenswürdige Code in Office 365nicht unterstützt wird. Die Umgebungen, die Sie sich entschließen, adressieren werden auch Auswirkungen wie Ihre app mit SharePoint authentifiziert. Im Wesentlichen, wenn Sie planen, Cloud und lokalen Umgebungen unterstützen, müssen Sie Ihre app wenig vertrauenswürdigen stellen. Wenn Sie beabsichtigen, nur lokalen unterstützen, müssen Sie die Wahl der hoher Vertrauenswürdigkeit oder wenig vertrauenswürdigen Anwendungen. Finden Sie im App-Vertrauensstellung und Berechtigungen weiter oben für weitere Details auf app Vertrauen.

Bereitstellung

SharePoint-Lösungen erfordern eine beträchtliche Planung, um diese POST. In der Regel müssen Sie nach einen Ausfall zu planen, um die Anwendungspools zurücksetzen. Dies ist noch nie ideal. Apps, können auf der anderen Seite zu einem beliebigen Zeitpunkt bereitgestellt werden, da sie nach einen Ausfall erfordern nicht, da sie Remote der SharePoint-Umgebung ausgeführt. Dies bedeutet eine app bereitgestellt und zu einem beliebigen Zeitpunkt der Tag mit wenig oder keine Auswirkungen auf die Umgebung installiert werden kann. Dies bedeutet nicht, dass eine app Auswirkungen auf den Inhalt in der SharePoint-Umgebung, da es sehr viel, wie die Verwendung von app-Ereignisempfänger, kann, die Code werden, während der Installation ausgeführt kann. Sie bedeutet, dass Sie nicht die SharePoint-Umgebung zurücksetzen müssen.

Apps für SharePoint werden letztlich bereitgestellt, um entweder die Office Store oder auf den internen app-Katalog. Die Office Store übergibt der Entwickler, die eine die app finanzielle oder es kostenlos an das Publikum zur Verfügung. App-Katalog ist im Kontext des Netzwerks einer internen Organisation verfügbar und nur für die Mitarbeiter der Organisation verfügbar. In beiden Fällen muss das app-Paket generiert werden, um die Webanwendung POST. Die genauen Art der Bereitstellung hängt von der Art der Umgebung, die die app durchgeführt wird. Beispielsweise generiert für eine Anwendung, die als Anbieter gehostete Anwendung veröffentlicht werden, den Veröffentlichungsprozess in Visual Studio-2012 die app-Manifestdatei (die APP-Datei), als auch mehrere Dateien für die Webanwendung. Die Webdateien und Komponenten müssen in der Umgebung der Webanwendung-Host bereitgestellt werden. Wenn Sie Ihre Anwendung als app Autohosted veröffentlichen, den Vorgang des Visual Studio 2012 -Publikation erstellt wird, nicht nur die app manifest App-Datei, aber auch die Dateien und eines Skripts, die Sie verwenden möchten, so veröffentlichen Sie die Host-Webanwendung, und es bettet die Webdateien und eines Skripts in der app-Paket. Wenn eine Autohosted-app für die SharePoint-Umgebung bereitgestellt wird, automatisch, werden die Dateien auf die Autohosted-Web-Umgebung bereitgestellt und führt die SQL-Skripts für die Autohosted SQL Server Datenbanken.

Entwurfsmuster

SharePoint-Lösungen ermöglichen für wirklich nur ein Typ von Web Development Muster, das Webformulare ist. Obwohl dies wurde eine Zeit getestet und "true" Weg für die Entwicklung von Lösungen für Jahre, gab viele Fortschritte in Webanwendungen, die nun ausgelegt werden möglicherweise mit dem MVC (Model-View-Controller) und Entwurfsmuster MVVM (Model-View-ViewModel). Beide Entwurfsmuster trennen die Ansicht von der Geschäftslogik einer Anwendung, so dass Sie mehrere Ansichten sein. Dies kann praktisch, um mehrere Ansichten für eine Gruppe von Logik unterstützen sein. Sagen Sie ein App für SharePoint könnte eine Ansicht, und eine Anwendung für Excel könnte einer anderen Ansicht. Beide dieser Ansichten können jedoch den gleichen Satz von Domänenlogik verwenden. Bei Webformulare würden Sie am Ende umschreiben viele der Domäne und Logik für die SharePoint-Lösung und die Office-Lösung zu rendern.

Das Cloud-App-Objektmodell ermöglicht eine locker gekoppelten Umgebung zwischen der SharePoint-Oberfläche und der Domänenlogik selbst. Dadurch können Sie mehrere Ansichten erstellen, die die gleiche Logik immer wieder verwenden können. Ein Beispiel wäre eine vollständige Immersionerfahrung (ganze Seite) und einer app-Webparts erstellen. Beide dieser Erfahrungen oder Ansichten die gleichen Domänenlogik verwenden können, und nutzen Sie häufig auftretende und beliebte Frameworks und Tools, die die Entwicklercommunity verfügbar sind.

Fähigkeiten

SharePoint-Lösung müssen Sie .NET, ASP.NET und SharePoint-Entwicklung-Kenntnisse verfügen, um eine Lösung zu erstellen. Es erfordert eine spezialisierte Fertigkeiten legen Sie zum Erstellen skalierbarer, zuverlässige und wertvolle Lösungen. Sie müssen die bewährte Entwicklungsmethoden für SharePoint zu verstehen, um eine stabil und zuverlässig-Umgebung zu gewährleisten. Das Objektmodell für das Cloud-App, Flexibilität auf der anderen Seite unglaublich mit Sprachen und -Technologien verwendet, um die neue Apps für SharePointerstellen. Beispielsweise können abhängig von der Webanwendung verwendete (wie weiter oben beschrieben) Form, die Anwendung und Datenlogik in der Cloud oder lokalen befinden, ob es auf Microsoft Azure und Microsoft Azure SQL-Datenbank, einige andere Cloud Dienste ausgeführt oder lokal auf allen Webservern ausgeführt wird. Da die Cloud-App-Modell eine mehrstufigen Architektur-Vorgehensweise zum Erstellen von apps unterstützt, die Benutzeroberfläche, die Logik und die Daten können in verschiedenen Ebenen verteilt werden und verwenden Sie unterschiedliche Programmiersprachen und entwerfen Paradigmen. Sie können apps in praktisch jeder Sprache Web schreiben, die standard webbasierte Standards wie HTML5, JavaScript, OAuth und REST verwenden können. Auf diese Weise können Sie code die Anwendungslogik der app für SharePoint auf einer beliebigen Sprache und jede Plattform, die Sie mit vertraut sind. Die primäre Visual und Benutzer wünschen Aspekte der app sind in JavaScript und HTML, die grundlegende Web-Standards, die Entwickler für die standardisierten Webentwicklung kennen sollten, die auf jedem Browser zugegriffen werden kann, sind codiert.

Der Cloud-App-Modell kann auch als Dienst Plattform verwendet werden zur Unterstützung von Anwendungen, die für andere Plattformen, einschließlich von Windows Phone 8, Windows 8, iOS und Android geschrieben. Können Sie schreiben die Darstellungsschicht auf diesen Plattformen in der systemeigenen Sprachen und Paradigmen auf diesen Plattformen verfügbar und verweisen Sie anschließend auf die SharePoint-APIs durch JavaScript Bibliotheken, REST, und WP und .NET Bibliotheken.

Die Leistungsfähigkeit von dieses flexible Entwicklungsmodell können Sie die mit der Entwicklung apps für SharePoint zum sofortigen Verbrauch durch Unternehmenskunden oder Verbraucher über die Office Store, ohne dass sich auf einem neuen Entwicklungssprache steigern. Können Sie damit POST Wert auf Ihr Unternehmen und unabhängige sofort, und Sie haben die Möglichkeit, die eine Ihrer app über die Office Storefinanzielle, oder geben Sie es ausschließlich in einem Enterprise-isolierten app-Katalog. In beiden Fällen können Sie zur Verfügung Wert sofort Ihre vorhandenen Fertigkeiten, das ermöglicht die apps für SharePoint bei modellieren Mehrwert, schnell entwickelt apps.

SharePoint ist zurzeit im gesamten Unternehmen und in vielen gehostete ISV-Bereitstellungen verwendet wird. Im Rahmen dieser Bereitstellungen wurden viele Anpassungen der-Plattform zu machen, eine nutzbare und produktive Umgebung für ihre Benutzer hinzugefügt. In diesem Abschnitt werden wir in mehrere wichtige Anpassungsszenarien an, die auf den vorherigen Versionen oder SharePoint bereitgestellt wurden vertiefen und bewerten zuerst diese Szenarien zu den neuen apps für SharePoint-Objektmodell migrieren.

Branding

Most instances of SharePoint that are currently deployed in the enterprise and ISV spaces have been branded with custom colors, styles, layouts, and logos in order to customize the SharePoint product to the corporate and provider identities. These solutions are provided on the portal-level across the entire SharePoint deployment to offer users a look and feel that is unique to the corporation and help drive the corporate culture and identity. These solutions are often deployed as a collection of master pages, page layouts, styles, and images that are grouped and deployed as a SharePoint solution. Given the scope of these customizations and that they are offered to the users of the entire SharePoint deployment, the solution must reside on the SharePoint servers. These solutions are often housed and deployed from the sandbox to avoid any problematic code from affecting the entire SharePoint farm. Therefore, any branding-type solution cannot by nature be migrated to an app for SharePoint. This doesn’t mean an app can’t provision brandied elements, it just means that it shouldn’t be done in the same way as a solution. For instance, you could use an app to provision branded content into your SharePoint environment. Another option for branding a SharePoint site would be using the new Design Manager feature in SharePoint.

For apps, the branding can be pulled back into the app for SharePoint instance, and the app can use the custom branding solution already deployed to the SharePoint instance. This is powerful in that the branding investment can be used in the new apps without the need to rewrite any code. For more information about the types of branding and styling options that you can use in the various hosting options, see UX-Design für Apps in SharePoint 2013.

Line-of-business

Another type of common customization performed on top of the SharePoint platform is a line-of-business solution. These solutions often use the capabilities of the SharePoint platform to connect users with in-context resources, such as BI dashboards, business data from external sources, custom workflow processes, platform automations and productivity enhancers for information workers, connections to ERP and CRM systems, and connections through Business Connectivity Services (BCS) in SharePoint to various external data sources and structures. In the past, these types of solutions would have been deployed as custom SharePoint solutions that would have to be added to the SharePoint server and provided with full-trust code access permissions to the SharePoint deployment and cause downtime each time they are updated.

Apps für SharePoint offer a secure alternative by providing the flexibility of having the actual line-of-business application code running in a variety of hosting options, and the in-context app running within the browser for particular users. The hosting options provide an easy alternative to solution hosting that limits the exposure of the SharePoint servers to the application logic and process without eliminating the ability to allow for business-critical applications that must interface with SharePoint. Apps für SharePoint can also access BCS natively through the SharePoint CSOM APIs or REST endpoints and display the data in a custom way through JavaScript. The additional benefit to having the line-of-business application logic hosted outside of SharePoint and only the presentation of the user interface and input surfaced through the app for SharePoint is that the line-of-business application can run on potentially any external server and in any language that has the capability of being exposed through web services. The various remote APIs available through the app model allow the app for SharePoint to communicate with these web services and display the user-relevant business information in the browser. This is incredibly powerful for businesses that have invested resources into building line of business applications on other platforms and languages, but would like to integrate them into their SharePoint deployment.

Forms and views

Forms and views are two more customizations that have been historically widely used within the SharePoint customization options. Forms and views let the enterprise and hosting providers give users a custom way to interact with data hosted inside of SharePoint or available through SharePoint from external data sources. These custom presentation options for data let users determine the most productive way in which to use and manipulate the SharePoint or external data.

Before SharePoint 2013, the common way to create forms and views was either with a custom ASPX webpage and/or using Extensible Stylesheet Language Transformations (XSLT). Apps für SharePoint let you surface the same type of custom data display and user input through an app rather than a full-trust code solution. An app for SharePoint allows for complete choice in how you render a form or view. You can use server-side rendering like XSLT or custom code, or it can be done client side with HTML. You have this flexibility because your app is not bound by the architecture of SharePoint to execute your code. Instead, you can use the architecture and framework of the web hosting platform that your app resides on. Thus you can easily use common web development patterns, such as Model-View-Controller and Model-View-ViewModel. This provides the same benefits as outlined earlier to the security and flexibility of apps for SharePoint, but it also allows for the same type of data display flexibility and user input customization as previously available in the full-trust code solution model. Therefore, any new forms and views that are available to enterprise users or ISV-hosted users can be created using the new apps for SharePoint model, rather than relying on full-trust code solutions.

Behandeln von Ereignissen

With SharePoint solutions, handling events is done with event receivers. You register an event, such as a list item added or updated, with a block of code, and whenever that list item is updated or something is added to the list, your code executes. It is a very popular feature, but it exposes the same risks that all full-trust code can to your environment.

The Cloud App Model introduces a concept called remote event receivers. They behave like event receivers, except that the custom code you write is executed remotely. SharePoint calls a Windows Communication Foundation (WCF) web service that you write, and that service executes code when the event occurs. This custom code can call back into SharePoint using REST endpoints or CSOM APIs just like an app.

SharePoint solutions also have feature receivers that execute when a feature is installed or removed. Apps have an equivalent remote event receiver called an app event receiver. These app event receivers have the same execution model as other remote even receivers, except that they execute when an app is installed, upgraded, or uninstalled.

Search and workflow

SharePoint 2013 introduced changes to some SharePoint services and web service end points. First, the Search service and workflow engines have changed: now SharePoint uses a new and improved search engine by default. This requires reevaluation of any existing solutions you have and the approach you take in writing apps or solutions that use search. The workflow engine in SharePoint 2013 is rewritten from the ground up. It follows the new app model and runs remotely from the SharePoint environment. In the past, you could write custom workflow activities with custom code. That is no longer the case in SharePoint 2013: custom activities are now HTTP requests that are defined declaratively. This allows for a scalable and stable workflow environment and will require any custom code to be defined in a web service.

The decision to write your next SharePoint customization as an app or full-trust solution should take into account the scenario you are trying to satisfy as well as the current environment landscape you are trying to target. If you are building for Office 365, the choice is pretty clear that apps are the way to go. If you are building a customization for the Central Admin, then a full-trust solution is the way to go. For some scenarios, you can choose either option. Typically, most organizations want to pick the best scalable method for customizing SharePoint while minimizing the effort to get the customization done. Typically full-trust code must be reevaluated when you are upgrading SharePoint to ensure that the customizations will not negatively impact the upgrade to the next version. Apps do not require you to do this at the same scale as full-trust code due to their loosely coupled nature. With an app, your main concern is to ensure that the data contract on the SharePoint service has not changed. With full-trust code, you have to be concerned with not only the data contract of the API, but also the behavior of the API and the environment your solution is running in. This includes both the SharePoint environment and the impact that any other custom solution may have on the SharePoint environment.

Full-trust code requires a deep understanding of the internal workings of SharePoint to build stable and scalable solutions. Apps require you to just understand the object model you are using because an app will not impact the performance or stability of the SharePoint environment. Another thing to consider is the application lifecycle of developing an app versus a full trust SharePoint solution. It is true that there is always some learning curve involved in learning different technologies, methodologies and programming languages. However, that is not the only factor to consider. Full trust code requires extensive lifecycle management processes and procedures to not only make sure the app itself works as expected, but to insure that the SharePoint environment including any other full trust customizations is also stable. Due to the isolated nature of apps, apps, in most cases, will not require that your application lifecycle processes test the SharePoint environment and other customizations along with your app.

With these considerations in mind, apps should be looked at as the primary choice, and full-trust solutions should be looked at when the capability of the app model does not meet the business requirements. I want to emphasize meeting the business requirements and not the technical requirements. It is true that how you implement a full-trust solution is not identical to implementing an app. However, don’t get trapped into mapping your server-side object model development skills to the Cloud App Model. There are differences, and the Cloud App Model will require you to think outside of the "full-trust box."

The main reason why you would still use full-trust solutions is that a feature or API you want to use is not yet available through the REST endpoints or CSOM APIs. However, this doesn’t mean you can’t still use the server object model from an app that is on-premises. It just requires some outside-of-the-box thinking. Instead of writing a full-trust solution that completely covers the entire business scenario you are trying to satisfy, write a full-trust solution that exposes the functionality you are looking for as a REST endpoint and write an app that can use that endpoint. This will allow your solution to scale while reducing the overall exposure of full-trust code to the SharePoint environment.

Anzeigen:
© 2014 Microsoft