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.