Monday, 12 May 2014

SharePoint 2013 Development: Solutions vs. Apps

From  Denis Stetsenko's  Blog----Posted on 

SharePoint Solutions and Apps image

SharePoint 2013, like all recent versions of SharePoint, is a great development platform that allows customizations via supported extensibility models. There are two ways to add custom functionality to SharePoint 2013: SharePoint Solutions and SharePoint Apps. At a high-level, we will cover each extensibility model, along with advantages and disadvantages of each approach from the development and deployment perspectives.
Overview of SharePoint Solutions (*.wsp)
SharePoint 2013 will support this classic model well-known to all SharePoint developers. SharePoint Solutions are still considered a good option, and in some cases the only option, for customizing SharePoint.
SharePoint Solutions can be developed using Visual Studio 2012, which includes a number of supported templates. They can integrate with external applications using Business Connectivity Services (BCS), Web Services, or a custom Service Application.
There are two types of SharePoint Solutions: Farm Solutions and Sandboxed Solutions.
Farm Solutions, first introduced in MOSS 2007, are fully-trusted and have access to the full server-side SharePoint API. They must be deployed by a Farm Administrator and run in the main SharePoint worker process. Customizations added via Farm Solutions are available to the entire farm, which makes them a great choice for a wide array of custom features, such as branding solutions and administration tools. SharePoint Solutions can also be scoped to individual Web Applications, Site Collections, and Sites.
Sandboxed Solutions, first introduced in SharePoint 2010, are partially trusted, and can only access a subset of the server-side SharePoint API. Another limitation is that they cannot make any calls to externally-hosted Web Services or databases, which can still be achieved using client-side technologies. Sandboxed Solutions can be deployed (uploaded) by a Site Collection Owner or Administrator via a browser and run in the SharePoint sandbox worker process. Customizations added via Sandboxed Solutions are available to the entire Site Collection, to which they are deployed, making them a great choice for an array of features, such as custom workflows or site/list/library templates. Even though Sandboxed Solutions are still allowed in SharePoint 2013, they are deprecated and should be avoided in favor of SharePoint Apps.
Introducing SharePoint Apps (*.app)
This is a brand new extensibility model introduced in SharePoint 2013 that addresses some of the inherent challenges with SharePoint Solutions. The biggest difference between apps and solutions is that apps run completely outside of the SharePoint server, meaning their custom code is executed either in the context of the client browser or on other servers not running SharePoint (i.e., any Web server hosted on premise or in the Cloud). Therefore, this model provides the highest level of app isolation. However, as a result, apps cannot natively interact with other apps. SharePoint Apps are generally scoped to individual Sites or a special Site called the App Catalog, which allows for other Sites to connect and consume the app.
SharePoint Apps can be developed using Visual Studio 2012, which includes a fully supported app template. They can also be developed using “NAPA” Office 365 Development Tools, a new set of tools for developing apps in a Web browser only available in hosted installations. SharePoint Apps can leverage any of the industry Web standards such as HTML5 and CSS3, JavaScript and jQuery (or any other frameworks/libraries), JSON, REST, OData, and OAuth. Thus, the options for integrating with external applications are vast.
There are three types of SharePoint Apps: SharePoint-Hosted Apps, Provider-Hosted Apps, and Azure Auto-Hosted Apps.
SharePoint-Hosted Apps are manifested entirely within SharePoint server and generally have no external dependencies. Their custom code is implemented by leveraging Client-Side Object Model (CSOM) or REST API, and is executed within the context of a browser. SharePoint-Hosted Apps can access libraries and lists to store content. Examples of these kinds of apps are PTO request or expense calculator.
Provider-Hosted Apps may have SharePoint components, similar to SharePoint-Hosted Apps, but the main business logic and data storage are manifested in an external infrastructure, such as an external Web server or in the Cloud. These apps are ideal for integration with external systems, such as a help desk support system. It’s important to note that Provider-Hosted Apps can also be developed using any other non-Microsoft tools and technologies, such as Eclipse or LAMP, due to the fact that their business logic and data storage are provisioned by the external infrastructure.
Azure Auto-Hosted Apps are somewhat similar to the Provider-Hosted Apps in that their main business logic and data storage are manifested in an external infrastructure. However, the Azure Auto-Hosted App package additionally contains the Website and database that is deployed and run outside of SharePoint. When this type of app is installed, SharePoint handles automatic provisioning of the Azure SQL Database and Azure-Hosted Website in an existing Azure account setup in the farm.
Development Considerations
SharePoint Solutions have inherent issues that stem from their complexity and that they run directly on the SharePoint server. Farm Solutions are the root cause of most SharePoint outages and errors; they are cumbersome to deploy and not suitable for hosted environments. Sandboxed Solutions have access to limited server-side API, but still require knowledge and experience with the server-side API. In addition, SharePoint Solutions are costly to develop and require performance monitoring to ensure they don’t affect the farm performance.
SharePoint Apps are now the preferred method for developing SharePoint customizations. They have the following advantages over SharePoint Solutions:

  • Stability: Since SharePoint Apps never run on the SharePoint server, this greatly increases the stability and performance of the farm. It makes it easier to upgrade to the next version of SharePoint since testing platform independent Apps is easier and faster than testing Solutions.

  •  Capability: SharePoint Apps can communicate with SharePoint via OData and CSOM. Microsoft has greatly improved the capabilities of the CSOM and the REST API to enable developers to create a wide-range of custom solutions without using the server-side API.
  •   Security: SharePoint Apps can leverage the newly added support for OAuth 2.0, which provides an easy way to manage their permissions. Developers can specify which permissions the app needs in order to function. The end-user installing the app is then prompted to accept the permission request the app needs to function.

  • Reusability: Apps can be packaged, reused, and sold via a Corporate or Public Marketplace, which makes it easy for end-users to acquire new apps. Also, the same exact app is guaranteed to work in both on-premise and Cloud environments.

  •  Deployability: Microsoft has made great investments in simplifying the app installation and upgrade processes; thus, addressing many developer challenges with the solution model.
What Should I Use?
SharePoint Apps are capable enough to replace most of the Farm and Sandboxed Solutions. Specifically, they are suitable for a wide range of customizations, including:

  •         Custom Web Parts
  •        Event and Feature Receivers
  •        Custom Field Types
  •        Application Pages
However, there are some SharePoint components which do not have an equivalent in the SharePoint App Model. Some types of customizations are only suitable for Farm Solutions, including:

  •        Custom Site Definitions
  •         Delegate Controls
  •         Custom Themes
  •          Custom action groups and custom action hiding
  •          User Controls
For more information on how to choose SharePoint Solutions or Apps, check out the article on “Apps for SharePoint compared with SharePoint solutions.”
Deployment Considerations
SharePoint 2013 can be deployed in three different ways: On-Premise Installation, Office 365 & SharePoint Online, and Hosted Installation. Farm Solutions can only be deployed to the On-Premise Installation of SharePoint. Sandboxed Solutions and SharePoint Apps can be deployed to all three different types SharePoint installations.
Conclusion
SharePoint Farm and Sandboxed Solutions are still supported in SharePoint 2013, but Sandbox Solutions are deprecated and should not be used. In some cases, Farm Solutions are either a better way or the only way for specific types of customizations. SharePoint Apps provide a brand new approach to extend SharePoint functionality and are now the recommended way to develop customizations for SharePoint 2013. They address several development and deployment challenges commonly associated with SharePoint Solutions, and allow developers to leverage a wide range of modern Web standards and technologies.


No comments:

Post a Comment