The SharePoint 2013 platform
supports three solution models for the now bewildering number of
customization opportunities on the SharePoint 2013 platform.
This section provides an overview of these three
models along with real-world guidance that you should consider when
deciding which model to use.
The three solution models can be summarized as follows:
- Farm solution model — The farm solution model, also known as the Fully Trusted Solution (FTS) Model,
enables you to deploy customizations directly to global assembly cache
(GAC) and web front end 15 hive or SharePoint Root folders. This option
provides the greatest power and flexibility in developing solutions for
your SharePoint 2013 environment. This model was introduced in
SharePoint 2007.
- Sandboxed solution model — The sandboxed solution model, also known as Partially Trusted Solution (PTS) Model,
enables you to deploy customizations directly to an individual site
collection. Partially trusted assemblies are executed in a separate
isolated process, called the user code service. This model was
introduced in SharePoint 2010. Microsoft has indicated that the
sandboxed solution model is available in SharePoint 2013, but has been
deprecated. This means you can still develop and use sandboxed
solutions, but that they may not be upgradeable to SharePoint Next.
Microsoft recommends moving away from the sandboxed solution model
wherever possible and using the new app model in conjunction with
client object models and out-of-the-box web services.
- SharePoint app model — The
SharePoint app model is a completely new model provided by SharePoint
2013. It enables you to develop solutions that can be hosted in a
corporate catalog and on the Microsoft Office Store Catalog.
To help you decide on the most appropriate model,
look at the over-arching considerations when deciding between each
model, followed by a side-by-side comparison of these models.
The over-arching considerations are as follows:
- Factoring in cloud-hosted farms —
The hosting location of your farm directly affects the solution models
available to you. For most cloud-hosted shared environments, the
partially trusted model and new SharePoint app model are your available
options. For cloud-hosted environments that take advantage of Microsoft
dedicated hosted offerings, all three models are available to you.
- Adhering to application governance policies
— It’s a tough job balancing the risk of a site outage (and end users
howling at you in frustration) versus allowing change to occur freely
and spontaneously to your production sites. Over time, especially in
large, mature SharePoint deployments, your SharePoint Application
Managers develop an appreciation and risk profile (based on experience,
wisdom, and pain) for the types of solutions and customizations they
support. These form the basis for application governance policies that
need to be adhered to.
- Supporting increased speed of change
— In some process-laden business environments, getting new solutions to
customers and end users deployed to your SharePoint 2013 farm can take
a long time. The design and model you employ directly affects the
length of time to get your customizations into production.
- Incorporating existing architectural approaches
— Many SharePoint 2013 deployments are the result of an upgrade from a
SharePoint 2010 environment. The upgraded customization and code base
will most likely come from 2007 and 2010 environments, and may
influence your approach to maintain existing solutions as fully trusted
solutions, while developing some of the new solutions (where possible)
using the new SharePoint app model.
A more detailed look at the strengths and weaknesses of each of these models are summarized in Table 1.
TABLE 1: Solution Models Side-by-Side Comparison in SharePoint 2013
In summary, Microsoft recommends, for the right
reasons, that you brush up on your JavaScript skills and leave the
beauty, cleanliness, and power of C# code in favor of the SP app model
wherever it makes sense. For lovers of JavaScript, this is your time to
jump for joy. Until the JavaScript development tools improve, and new
toolsets (such as TypeScript) mature, some people will shed a tear or
two.
The cold, hard reality is that many
existing on-premise deployments have invested a significant amount of
time, energy, and money, over many years, developing customizations
that will still require server-side
execution. There is also no getting around it that a vast number of
customizations still require server-side code execution. Based on this,
the most reasonable, balanced, and sensible approach is to slowly
reduce your reliance and dependence on full-trust and sandboxed
solutions over time, and cautiously introduce the new SP app model for
new customizations where possible.
