1. Application and Solution Types
When developing applications
for SharePoint, remember that you have a few different ways to build
and deploy a SharePoint application or solution. The following is a
short list of the types of options — both historical and today:
- Farm-level solution: Typically
associated with either SharePoint Server or SharePoint Foundation, this
type of solution (.WSP or SharePoint feature) is an application that is
installable and accessible across any site collection within a
SharePoint farm.
- Sandboxed solution: Lightweight
solution or feature that is deployed to a sandboxed environment (that
is, a restricted execution environment that allows programs to access
specific resources and data within the SharePoint site) and can be
deployed to Office 365 or on-premises SharePoint installations.
- SharePoint-hosted app: Lightweight app (.APP) that is deployed to SharePoint but leverages client-side code such as HTML, JavaScript, and CSS.
- Cloud-hosted app: Apps (.APP) that
are hosted in the cloud, but can be deployed to either SharePoint
on-premises or Office 365. These are either Autohosted or
Provider-hosted .
Each one of these options has pros and cons that
you will need to understand — not only so you can choose between them,
but also so you can really take advantage of all the services, APIs, or
features that are available within each one of these options. You may
also have combinations of a few of these options — you’re not relegated
to just using one or the other. For example, you may combine
SharePoint-hosted with Cloud-hosted.
INSTALLATION TYPE MATTERS
The type of SharePoint installation
(SharePoint Server or Office 365) also plays a role in choosing a
development solution and choosing the APIs to use within that solution.
For instance, if you’re building an application for SharePoint
Foundation or SharePoint Server, you can develop and deploy solutions
that have farm-level scope (farm-level solution). You also can use a
broader set of SharePoint-specific APIs; that is, you can use both the
Server-Side Object Model and the Client-Side Object Model. If your
target installation is Office 365, you will likely use Cloud-hosted
apps, in which case you won’t use the Server-Side Object Model, but
design your apps using the Client-Side Object Model and more broadly
the Windows Azure platform.
Table 1 further explores some of the differences you need to think about across the development options.
TABLE 1: Considerations Across SharePoint Deployment
Note that if your target SharePoint installation
is SharePoint Server, then you have the option of using the farm-level
solution, which supports all the different types of app development. In
regards to being able to leverage SharePoint APIs, services, and
features, the farm-level solution is the most powerful out of the
different solutions (as measured by the breadth of SharePoint API you
can use).
Sandboxed solutions, inversely, are the most
restricted. You can build some interesting applications with them, but
they do not affect the whole server farm (unlike the farm-level
solution), and they can be deployed by the site collection
administrator and are isolated to resources within the site collection
to which they are deployed.
You might think of SharePoint-hosted apps as
sister apps to the sandboxed solutions. They are also lightweight apps
that are meant to leverage site collection resources and artifacts;
however, one of the key differences is that you typically leverage
unmanaged code to build these apps. Also, as mentioned earlier, the
cloud-hosted apps are pretty powerful; you can deploy them on full
installations of SharePoint (for example, SharePoint Server) or you can
deploy them in Office 365. They bring the broader elements of the cloud
into SharePoint and can leverage some of the core REST APIs and
client-side object model.
With these points in mind, you might be asking yourself in what situation do you use one over the other. Although Table 1 provides some measure of differentiation, Table 2 provides a little more guidance around when you might use one option over the other.
TABLE 2: Recommendations on When to Use Which Option
| CONSIDERATION |
WHEN TO USE |
| Farm-level solution |
Use this solution for
applications being deployed to SharePoint Server or SharePoint
Foundation. Suitable for enterprise-grade solutions (such as Sales
Management dashboard that is integrated with SAP) that require
farm-level (or site-collection level) resource access, cross-site
collection deployment, or need to execute server-side code. |
| Sandboxed solution |
Given the strategic direction toward the
cloud-hosted model, it is recommended that moving forward you should
use the SharePoint-hosted model instead of the sandboxed solution.
(While supported for backward compatibility, these are marked as
deprecated in MSDN.) |
| SharePoint-hosted |
Use when you have smaller, lightweight
apps that are centric to a specific site collection or SharePoint page
(for example, custom list view on a Web page or custom content type).
If you have any server-side code requirements, you cannot use
SharePoint-hosted apps. |
| Cloud-hosted |
Use when you don’t want any running code
on the server, if you’re targeting Office 365, or if you want to build
a Web app on a different infrastructure (e.g., Google, Amazon, LAMP,
etc.). Use Autohosted for smaller-scale apps (for example, ASP.NET data
views or forms) and Provider-hosted for enterprise-grade cloud apps
(for example, expense apps that use third-party state-level services to
calculate tax). The client-side object model or REST APIs can
substitute some of the server-side object model functionality
(especially when interacting with list data). Also, you must manage
your own hosting of the app for Provider-hosted apps and the
permissions/app authentication for either Autohosted or Provider-hosted
depending on what you’re trying to accomplish in the app. |
In general, you’ll find that the more SharePoint
applications you develop the better sense of what to use for a
particular situation you’ll have, and you’ll begin to ask a specific
set of questions as you start to gather requirements for your
SharePoint applications. These questions will range from understanding
the installation scenario to data security to business process and
workflow to leveraging third-party services.
NOTE
A word of advice to those of you starting out as SharePoint developers:
always look to see whether what the business is asking for already
exists within SharePoint before you re-create it. You will save time
and money by leveraging the extensive amount of out-of-the-box features
that are available to you.
While understanding when to use a
specific scenario is important, so are the common developer tasks and
skills that you’ll need to leverage in your day-to-day SharePoint
development career. With that in mind, let’s talk about the more common
tasks in which you can expect to engage as a SharePoint developer.
