SharePoint sandboxed solutions are deprecated in SharePoint 2013 in favour of developing apps for SharePoint, but sandboxed solutions can still be installed to site collections on SharePoint 2013. This topic compares apps for SharePoint with farm solutions. The latter are packages of SharePoint components that are uploaded to a farm-wide gallery from where they can be installed.
Why to develop an app than classic solution?
Apps for SharePoint have the following advantages over classic solutions:
· They provide users with the easiest discovery, purchase, and installation process.
· They provide administrators with the safest SharePoint extensions.
· They provide you with the simplest marketing and sales system based on a Microsoft-provided online app store.
· They maximize your flexibility in developing future upgrades.
· They maximize your ability to leverage your existing non-SharePoint programming skills.
· They integrate cloud-based resources in smoother and more flexible ways.
· They enable your extension to have permissions that are distinct from the permissions of the user who is running the app.
· They enable you to use cross-platform standards, including HTML, REST, OData, JavaScript, and OAuth.
· They enable you to leverage the SharePoint cross-domain JavaScript library to access SharePoint data. Alternatively, you can use a Microsoft-provided secure token service that is OAuth-compliant.
· They can extend SharePoint Online websites as well as on-premises SharePoint websites.
Apps for SharePoint use one of the SharePoint client object models or REST endpoints to access SharePoint content and components. These client APIs enable SharePoint extensions that are designed for end users. (The end users in this case are site-collection administrators, website owners, and website members.) The server object model has APIs that enable programmatic extensions of SharePoint management, configuration, and security. These include extensions of Central Administration, custom Windows PowerShell commands, timer jobs, custom backups, and others. For more information about the kinds of administrative extensions you can develop, see SharePoint Foundation Administration. These administrative extensions are deployed in SharePoint Features that have farm, web application, or site-collection scope. Farm solutions are also installed by farm administrators, while apps can be installed by tenant and site collection administrators.The server object model also has APIs for create/read/update/delete (CRUD) operations on lists, libraries, websites, and operations on other SharePoint components. This means that the server object model can be used for extensions that are intended for end users, but for reasons given in the preceding section, farm solutions are not usually the best choice for such extensions. Thus, it is no surprise that farm solutions cannot be installed on Microsoft SharePoint Online. Because Microsoft handles all the management of SharePoint Online, there is no need for administrative extensions. For more information (and a diagram) about the various APIs in SharePoint and where they overlap, see Choose the right API set in SharePoint 2013.
The client object models and REST endpoints do not duplicate the administrative-oriented APIs of the server object model. Moreover, because an app for SharePoint cannot contain custom code that runs on the SharePoint server, it cannot call these administrative APIs. Moreover, all Features in apps for SharePoint must have website scope. Thus, an administrative-oriented SharePoint extension is not really possible with an app for SharePoint. So the second guidance principle, but not an absolute rule, is that apps are for end users and farm solutions are for administrators.
As noted earlier in this article, custom code that runs on the SharePoint servers is not allowed in apps for SharePoint. This is not a significant limitation. It simply means that your custom business logic moves either "down" to the client device or "up" to the cloud. In either case, you can use the SharePoint REST/OData service to access SharePoint sites, lists, and other data. You can also remotely access SharePoint data through the SharePoint JavaScript, Silverlight, or .NET Framework client object models. Finally, on Windows Phones, you can access SharePoint through the SharePoint Windows Phone object model. For more information about the various sets of APIs in SharePoint 2013, see Choose the right API set in SharePoint 2013.
A similar point applies to the fact that Features in apps for SharePoint cannot have site collection, web application, or farm scope. This doesn't mean that you give up some user interface (UI) element or functionality. It simply means that the implementation of the component moves out of SharePoint and onto a client or remote web application or remote database.
The following table lists the SharePoint components that cannot be deployed in an app for SharePoint and describes the "app way" of getting the same functionality.
If you want the functionality of ...
|
... try these approaches.
|
Custom Web Parts
|
An app for SharePoint can have remote pages that contain custom Web Parts. Another option is to expose a page from a remote web application in an app part on a SharePoint site page. The remote page can have essentially the same UI controls and functionality as a Web Part. For more information, see How to: Create app parts to deploy with apps for SharePoint.
|
Event receivers and Feature receivers
|
An app for SharePoint can contain functionally equivalent remote event receivers. For more information, see Handling events in apps for SharePoint.
|
Custom field (column) types
|
An app can deploy a new field (column) that is based on one of the existing field types. The Calculated and Computed field types are especially flexible. Another option is to present your data in a remote web page with customized controls or grids.
|
Custom web services built on the SharePoint Service Application Framework
|
You can develop your custom web services as remote services.
|
Application pages
|
An app for SharePoint can include remote web pages that are available from every website on which the app is installed. An app can also use any of the built-in SharePoint Web Parts on site pages.
|
Some SharePoint components are used in end-user scenarios but do not have any equivalents in the SharePoint app model. For these you must use farm solutions.
· Custom site definitions
· Delegate controls
· Custom themes
· Custom action groups and custom action hiding
· User controls (.ascx files) No scenario actually requires these.
No comments:
Post a Comment