When SharePoint first came out in 2001, development for the platform wasn’t easy. It was ASP—not ASP.NET, which was the first development approach for SharePoint. In 2003, the platform was migrated to .NET, but it wasn’t until 2007 that it had a proper customization strategy in the form of features and solutions. The world has changed since then, and SharePoint has had several development models come—and one has both come and gone. In this article, we’ll look at the development models available in SharePoint and Office 365 development and explain why one would choose one model versus another.
Introducing the Development Options
The last four years in SharePoint have been tumultuous, to say the least. Of the five models available, three were introduced in the last four years. These are the five models:
- Server-Side Object Model (a.k.a. Server Solutions): Introduced in 2007 and available today for on-premises deployment, this model has the richest support and the greatest longevity, but puts a great deal of onus on the developer to write good code, because the code runs directly inside the SharePoint processes.
- Sandboxed Solutions (a.k.a. User Code Host, Partially Trusted Callers): Introduced in 2010, these solutions allowed end users to write to a subset of the SharePoint API. These solutions had severe limitations but were designed to reduce platform instability with poorly-behaved developer code. It’s no longer available on Office 365/SharePoint Online and is not planned for further investments.
- Add-Ins (previously known as “Apps”): Released with SharePoint 2013, these client-side-based applications run on other servers or in JavaScript in the browser, so they eliminate the challenges of server-side code. The complexity of this model, which includes the required wildcard DNS entries and authentication changes, required a different (and some say greater) developer skill set. Add-Ins are available both on-premises and online.
- Azure AD Apps: Though technically not a SharePoint development option directly, Azure AD Apps are applications registered with Azure Active Directory that can have their own security assigned in SharePoint and can leverage SharePoint for storage. They’re available only for SharePoint Online implementations due to the Azure AD requirement.
- Framework: A new programming model designed to plug into the redesigned user interface. Currently available online but “coming soon” to on-premises deployments.
In addition to the basic approaches to development, there are two different APIs to consider—for the apps that run online.
SharePoint APIs or Microsoft Graph
When working off the server, there’s always the question of which API to choose. The basic SharePoint API offers several options, including SOAP- and RESTful Web-services as well as a client object model. Fundamentally, these all approach the SharePoint API directly and are therefore scoped to operations that only involve SharePoint. Most of the time, this makes sense and isn’t a practical limitation.
However, in an online world where SharePoint isn’t the only thing that you want to access, there’s another Microsoft API, the Microsoft Graph API, which can be used to access many online resources including SharePoint, Exchange, Azure Active Directory, and more. The Graph API is a common authentication against all these resources.
The challenge is that Microsoft Graph is only available online, so if you’re developing for on-premises, you’ll be using one of the SharePoint APIs.
Configuration Before Code
Though we’ve been focused on coding options, it’s important to note that the best SharePoint solutions are solutions that don’t require code. SharePoint has a substantial amount of customization possible from the Web user interface and from SharePoint Designer. When designing solutions, our first choice of a development option should be no development.
Although it may not be possible to maintain the position that no code will be necessary for your solution, it might be possible to get by without code for a while or insert some JavaScript on a page to take care of a small need. If not, you’ll have to decide whether you’re developing for on-premises, online, or both.
On-Premises, Online, or Both
If you’re only ever going to develop for on-premises deployments, the tried and true Sever-Side Object Model isn’t a bad option. There are plenty of resources on how to do this kind of development. It’s relatively straightforward for any developer who has been building Web sites for a few years in C#. Of course, you can still do sandboxed solutions on-premises, but this isn’t typical.
Conversely, the Azure AD Apps and the Framework options are only available online. You can’t choose these options for on-premises deployments.
In the middle category—which can be used both online and on-premises is the Add-In model. When apps are written for the Add-In model using the SharePoint API, they can be used both on-premises and online.
Figure 1 shows a flow chart depicting the two “how” features—online only or on-premises only.
Figure 1: Deciding which option to use
Considering Context
A final consideration for choosing which option to pick is whether you intend to integrate to the SharePoint user interface, or whether you intend to have your own interface and are using SharePoint for storage of information. Framework integrates into the UI, as can the Server-Side Object Model and Add-Ins, but Azure AD Apps do not. Sometimes, the desire to create a single dashboard view of everything means picking a development solution that is designed to change the SharePoint user interface.
Lamenting the Limitations
Perhaps the greatest complaint about all the options—after needing to learn them all—is that each model has its own quirks and limitations. You often can get down the road in one approach to find that a critical API or need isn’t exposed, and you’ll have to regroup to a different approach. Even though that’s frustrating, it’s nice to know that there are other options available.
