SharePoint Development Model History

As we cover in the previous post of SharePoint History that SharePoint was launched as an on-premises product in 2001. Over time, a large developer community has extended and shaped it in many ways. For the most part, the developer community followed the same patterns and practices that the SharePoint product development team used, including web parts, SharePoint feature XML, and more.

SharePoint Development HistoryFigure 1 : History of SharePoint Development

Farm Solutions :

Typically, farm solutions are packaged as SharePoint solution package (WSP) files that contain assemblies, other non-compiled components, and an XML manifest file.

Many features were written in C# code, compiled to DLLs, and deployed to on-premises farms wich makes calls to the SharePoint server object model. These assemblies always run with full trust. Moreover, the Features in farm solutions can have scope as wide as the site collection, web application, or whole farm.

So that architecture worked well in environments with only one enterprise, but it didn’t scale to the cloud, where multiple tenants run side-by-side. As a result, Microsoft introduced two alternative models: Client-side JavaScript injection, and SharePoint Add-ins.

SharePoint Development Model Types : SSOM, CSOM, JSOM (SharePoint 2013), REST.

 

SharePoint Add-ins :

A SharePoint Add-in is a self-contained pieces of functionality that extends the capabilities of SharePoint websites to solve a well-defined business problem.

There are two basic kinds of SharePoint Add-ins : SharePoint Hosted and Provider Hosted.

The implementation of SharePoint Add-ins creates an iFrame where the actual experience resides and executes. The advantage is that because it’s external to the system and has no access to the current DOM/connection, it’s easier for information workers to trust and deploy. End users can install add-ins on NoScript sites.

There are a some downsides to this approach :

  • SharePoint Add-ins they run in an iFrame.
  • The iFrames are slower than the script editor web part, because it requires a new request to another page.    

SharePoint Development Model Types : CSOM, JSOM (SharePoint 2013), REST.

 

Script Injection :

One of the most popular web parts in SharePoint Online is the Script Editor. You can paste JavaScript into the Script Editor web part and have that JavaScript execute when the page renders.

It’s simple and rudimentary, but effective. It runs in the same browser context as the page, and is in the same DOM, so it can interact with other controls on the page. It is also relatively performant, and simple to use.

There are a couple of downsides to this approach :

  • Code isn’t packaged and deployable as a component
  • Code cannot be added to the app store
  • The end user can edit the page and modify the script, breaking the web part.
  • If “NoScript” feature is enabled the script editor web part will be blocked from executing on the sites.

SharePoint Developement Model Types : JSOM, REST.

 

SharePoint Framework (SPFx) :

The SharePoint Framework (SPFx) is the new development model, is a page and web part model that provides full support for client-side SharePoint development, easy integration with SharePoint data, and support for open source tooling. With the SharePoint Framework, you can use modern web technologies and tools in your preferred development environment to build productive experiences and apps that are responsive and mobile-ready from day one.

The SharePoint Framework works for SharePoint Online and also for on-premises with (SharePoint 2016 Feature Pack 2).

SharePoint Developement Types : Javascript Frameworks (ReactJS, VueJS, AngularJS, Knockout).

 

Note : We will detail more about each Development solution of SharePoint in the next posts about how they works and they interact with SharePoint server or cloud.

 

Stay tuned :).

Hope it will be helpful.

Add a Comment

Your email address will not be published. Required fields are marked *