SharePoint Development Models
Through this article, we are going to have an overview of the different SharePoint development models. Let’s get into it!
Introduction
Before building an application, we have a large amount things to think: needs, goals, architecture, infrastructure, frameworks and so on. Developing for SharePoint add an additional layer of complexity because we have to choose between various ways to work.
Each SharePoint development model has its purposes, advantages and difficulties. Here, we are going to have an overview of those different models.
Farm Solutions
Also known as Full Trust Solutions, they require to be developed on a SharePoint server and have access to full server-side SharePoint API. They are supported in SharePoint on-premise installations and have to be deployed by a Farm Administrator and the various features they can contain are then available to the entire farm.
Farms Solutions are distributed as wsp packages and can have different scope: Farm, Web Application, Site Collection or Website. They support things like Features, Event Receivers, Timer Jobs, WebParts, Modules and so on.
When we deploy a Farm Solution, we have to keep in mind that an IIS Reset will be performed.
Sandbox Solutions
Because Farm Solutions are very permissive, Microsoft introduced another kind of solution: Sandbox Solutions. Their scope is smaller because they can only target the Site Collection and have access to a small subset of the server-side API.
The wsp packages can be deployed to a Solutions Gallery and they don’t force the server to reset and while a Farm Solution can bring down the whole farm, a Sandbox Solution has only impact on a Site Collection. They are very useful to deploy assets or Content Types and Lists.
Sandbox Solutions are now deprecated, but they can still be used.
Add-Ins
Also known as Apps, SharePoint Add-Ins are deployed in the App Catalog, in the form of an .app file, public or private, and provide a way to develop an application without any server-side code executing on the SharePoint server. This means that Add-Ins run either in the context of the client browser or on another server.
This model introduced with the concept of the Office Store and Cloud-related things in mind, provides a high level of isolation. Add-Ins require working with the Client Side Object Model (CSOM) or the REST API.
Microsoft claims that a Farm Solution can be converted into one or various Add-Ins. However, create things that could easily be done with a Farm Solution with an Add-In can be tricky.
SharePoint Add-Ins come in various flavors:
- SharePoint-Hosted
- Provider-Hosted
SharePoint-Hosted Add-Ins are installed on a SharePoint Website, called the Host Web while their resources are hosted on an isolated subsite called the App Web. They only support JavaScript, a few ASPX files and XML. SharePoint-Hosted Add-Ins can access data and resources that are outside of the App Web by using one of the following techniques to bypass the browser’s same origin policy: a special JavaScript cross-domain library or a specific JavaScript WebProxy class.
Provider-Hosted Add-Ins include components that are deployed on another server while they are installed on the Host Web. It means that we are able to run server-side code on another server and to communicate with SharePoint using CSOM. They offer a great flexibility to develop the various elements we need.
If we can create WepParts with Farm Solutions, Add-Ins offer something similar called Add-In Parts, or Client WebPart. This concept is similar to WebPart, but it implies that the Add-In Part displays a webpage that we specify by using an IFrame in a page in the Host Web.
SharePoint Add-Ins are security principals that need to be authenticated and authorized and this can be done in various ways. An Add-In uses permission requests to ask for the permissions it needs. The permission requests specify the rights that the Add-In needs and the scope at which it needs the rights.
SharePoint Framework
Also known as SPFx, the SharePoint Framework is the most recent addition to the SharePoint developer toolbox. It provides full support for client-side development it grows with the development of SharePoint Online. It allows us to develop components using modern web technologies such as React. For now, the support of this framework is more advanced in SharePoint Online and it is only possible to develop WebParts and Extensions.
One advantage of this framework is that we don’t need SharePoint to be installed on our machine to develop. We just have to download a few Node packages and to run our server using Gulp. When we compile what we developed, we also get an .app file.
Conclusion
Through this article, we saw the various existing ways to develop for and with SharePoint. We saw the main idea behind each model, what they have in common and how they differ. We saw that Solutions use server-side API and Add-Ins aim to execute in a client context. We also had a small overview of the SharePoint Framework.
One last word
If you like this article, you can consider supporting and helping me on Patreon! It would be awesome! Otherwise, you can find my other posts on Medium and Tumblr. You will also know more about myself on my personal website. Until next time, happy headache!
