Introducing the SharePoint 2013 Development Models

The use of apps is now incredibly common. People use them every day on their smartphones, tablets, desktop operating systems, and even social networks. While using the SharePoint Solution model, there is no way to define a precise border to implement an app. With a solution, we can create lists, workflows, Ribbon control extensions, event receivers, web parts, and more. Each artifact might be independent of others (depending on the logic that you create, of course). A workflow is completely independent with respect to an event receiver or a web part.

It is true that, by working together, you can implement a concept of an app, but the Solution model was created to extend SharePoint rather than create apps. The concept, more like an app in earlier versions, can be assimilated to a web part that reads or writes data in lists or libraries (this is very risky, but it's just an example).

With the introduction of SharePoint 2013, Microsoft has reinvented this concept and is now offering a new development model for a new concept of apps and extensibility. First, let's recap the current development patterns that SharePoint 2013 offers us:

• Farm solutions
• Sandbox solutions
• App model

Farm Solutions

Farm solutions are how Microsoft has enabled developers to install customizations in SharePoint since the 2007 version. Technically, these are cabinet files with a .WSP extension. Internally, a SharePoint Solution Package (WSP) contains the dynamic-link library (DLL), possibly ASP.NET WebForm pages, user controls, images, Cascading Style Sheets (CSS), JavaScript files, and various resource file element.xml that go to inform how SharePoint will have to go to install all of these things.

The farm solution pattern is very powerful because it allows us to fully extend SharePoint capabilities. We can install files inside the SharePoint installation folder, use the server-side object model that SharePoint provides, run code with privileges higher than those of the current user, and expand the SharePoint engine with event receivers, blocking just the operations that the user is doing on our own logic. In short, we have full control over our SharePoint solution.

But, as always, too much power can sometimes hurt.

When we develop a farm solution, we must always consider the fact that we have the SharePoint engine in hand.

In addition to this, we have a number of things that we must do:

1. We must use objects that SharePoint offers us in the most effective way possible, otherwise we run the risk of overloading the SharePoint farm.
2. The code that we implement must be developed using the same version of the .NET Framework with which SharePoint has been developed.
3. The development environment requires that SharePoint is present locally in conjunction with Visual Studio. This means having an available virtualization system for development or a personal computer powerful enough to run a SharePoint farm.
4. In order to install our customization with this mode of installation in a production environment, we must access the farm with administrative privileges and work with PowerShell to execute a series of commands which serve both for installation and activation.

Sandboxed Solutions

This type of solution was introduced with SharePoint 2010 and its main purpose is to be able to install customizations even to users who are not farm administrators.

In order to do this and maintain a certain level of security, this type of solution is limited compared to farm type solutions. For example, you cannot deploy any type of file on the file system. The object model is limited, preventing the code from accessing the majority of objects that are logically above the Site Collection.

Sandboxed solutions are monitored, per site collection, for resource usage based on default quotas to prevent using too many system resources. 

If one or more sandboxed solutions exceeds the quota that was set for the site collection, all sandboxed solutions in that site collection will automatically be stopped.

Each night a timer job runs and resets the daily resource usage quota for all Sandboxed solutions in all site collections.

Obviously, these limits are designed to keep the SharePoint farm secure and, at the same time, give a less restrictive level to installing customizations on different sites.This model was the only way to install customizations in the SharePoint Online version since it was implemented using the 2010 version.

Currently, this model has been deprecated in favor of the new app model (at least with regard to the solutions that contain server-side code).

App Model

The app model is the new model introduced by Microsoft in SharePoint 2013 which is only available for this version and SharePoint Online (Office 365). This new pattern radically changes the way you think and develop when compared to the two models described earlier.

The main idea of this model is that the code that we implement will no longer run inside SharePoint, but instead, completely on the client-side (or server-side, but hosted outside of SharePoint), whether this means within a browser or inside a web server application such as ASP.NET, PHP, JSP, Node.js, or any other technology. This is indeed a major change, as anyone who has already developed in previous versions of SharePoint can definitely understand.

The development is done using the latest client-side technologies that the web offers including HTML5, CSS3, and JavaScript. However, it also uses technologies such as OAuth for security and OData to REST calls or the Client-Side Object Model (CSOM) to communicate with SharePoint.

In this case, SharePoint becomes a system that provides services to our app, and especially the ability to install and run them. SharePoint provides all functionality out of the box (OOTB) in authentication mode, and specific permissions have been granted to the app and to the user.

With the model of the app we have a unified model of development, making it possible to actually install applications on SharePoint 2013 rather than on Office 365, without having to recompile or modify the project.

In addition to this, Microsoft has made available a broader set of options for providing apps for SharePoint:

5. Public Office Store: Publish your app to the Microsoft Public Office to make the App Store publically available.
6. Internal Organization App Catalog: Publish your app to an internal organization’s app catalog hosted on your SharePoint deployment. This makes it available only to users with access to that SharePoint site.
7. Manual installation.

Over the course of the following chapters I will dive into the course. However, let’s first analyze the main topics for the new app model:

• It is easy to migrate to future versions of SharePoint; this is because the code is no longer performed in the SharePoint process.
• Developers, thanks to client-side API, may have less knowledge of the internals of SharePoint than farm solutions development.
• The ability to use not just .NET but other technologies is available, in addition to the ability to scale those applications on different systems.

An unquestionable advantage is that in order to develop an app, you no longer need to have a local SharePoint instance. Instead, you can work completely remotely, even using a Developer Subscription of Office 365.

1. Solutions vs. app model

Client API

When you are unable to execute server-side code in SharePoint, the only way to communicate is to use client-side application programming interfaces (APIs) that allow us to access most of the features that SharePoint provides.

Depending on the type of application and platform that has been chosen to build the app, you can choose between:

• .NET Client Object Model (also known as a Client Object Model for Managed Code)
• JavaScript Object Model
• REST/OData

For example, if we choose to create a SharePoint-hosted app, we can decide to use the JavaScript CSOM or use Rest/OData endpoints because the main platform used is JavaScript. (Nobody forbids us to use SilverLight in a SP-hosted app, but now the plug-in for browsers has become somewhat obsolete from an architectural point of view.)

Or, if we decide to create a provider-hosted app using .NET technology, the .NET CSOM is the most appropriate. It is true that we can also use Rest/OData endpoints here, but it's definitely more convenient to use, in this context, a typed object model.

If we create a self-hosted provider using any web platform we want (PHP, Node.Js, Java, etc.), we are almost forced to use REST/OData endpoints as there is a version of the CSOM adapted to all technologies.

In the next chapters, we will further discuss these aspects.

Summary

In this chapter, we looked at models that SharePoint offers us to create customizations or apps. In the following chapters, we will address the development of apps using the new app model.