Server-side development

The Server Object Model (Server OM) is an application programming interface that supports full interaction with all of the SharePoint configuration and data, and it is organized according to the conceptual system hierarchy which allows easy navigation for people familiar with SharePoint. All of the main objects are available with properties, methods, and sub-objects accessible. There is also a series of Context objects that make it easy to find or set your starting point such as the site the user is on, when the solution is called.

Frequently Used Objects and Collections include:

Object	Description
SPFarm	The object representation for the entire SharePoint system. Parent object to the SPServer and SPService collections.
SPSite	Represents a Site Collection
SPWeb	Represents a Web or Sub-site
SPList	Represents a List or Library
SPListItemCollection	Represents the items within a list or library
SPField	Represents a single field
SPListItem	Represents a single list item
SPContext	Represents current HTTPContext information including information on the current site and user.

All code has to be deployed to the server and references the SharePoint objects is loaded on the local server. Using the Server OM, you can build robust solutions and automate configuration changes. A few examples include custom Web Parts, Application Pages, Event Receivers, custom Timer Jobs, custom Workflows, custom Workflow Activities, custom web services, or even create a custom Service Application that can extend the services of the SharePoint platform.

With the 2010 version there are now two options for developing solutions; farm solutions and sandbox solutions.

Farm solutions

Creating farm solutions has been the traditional way to create solutions in SharePoint going back all the way to the earliest versions. The Server OM provides access to the system configuration and data allowing developers the ability to create solutions or automate configuration changes.

When deployed, the solution's objects are either loaded into the server's Global Assembly Cache (GAC) or into the 'bin' directory of the Web application(s). This allows farm solutions run in the same memory as SharePoint, which means the developer can have full access to the server, farm configuration, and content. These solutions do not have the overhead of the sandbox solution's process overhead and it also allows the developer to access additional caching features available inside of SharePoint to optimize the solution's performance. This does add risk though since poorly written or tested solutions can impact overall system performance or potentially crash the system.

Farm solutions can only be deployed by a Farm Administrator, and in many cases the Governance policy may also dictate a formal review or change management process to be followed before the Farm Administrator is allowed to deploy the solution.

Farm solutions are scoped for activation at a set level: Farm, Web Application, Site Collection, or Web allowing the developer to set it based on how and where the solution will be used. Take a look at the following figure for an illustration. A generally best practice is to scope a solution as narrowly as possible to provide more control on where it is activated. It is also important to note that solutions scoped for Site or Web can be activated by their respective owners based on site permissions.

Good candidates for farm solutions include:

• Custom MasterPages, PageLayouts, and global CSS

• Complex Web Parts

• Complex Application Pages

• Complex Workflows

• Complex Event Receivers

• Global Navigation Providers

• Complex Cross-Site or Cross-Web Application Roll-ups

Sandboxed solutions

Sandboxed solutions were introduced with SharePoint 2010 and provide an interesting shift for custom solutions offering a path for user created and maintained server solutions. Unlike the farm solutions previously discussed, these are partially trusted solutions and there are some limitations. Where the farm solutions run in the same memory space as the main SharePoint services and application pools, Sandboxed solutions run in an isolated memory pool with resource quotas that can be managed by administrators. This means that poorly written or tested solutions cannot slow down or crash your main server processes. If a solution is having trouble running it will be automatically disabled. In addition, the resource throttling and quotas can limit the amount of resources each solution can consume within the site collection. This safe mode approach can speed up development cycle, but should not remove the need to properly test your solutions.

This separation does come at a cost though and there is some process overhead involved with communicating across the different worker processes. In cases where the solution will be actively used by a large number of people, it may be more difficult to meet any scalability requirements.

Unlike farm solutions, developers or site administrators do not need administrative access to the physical servers or to the farm's Central Administration to deploy their solutions; they only need access to upload the solution to the Solution Gallery for a specific site collection. This provides custom solution capabilities to organizations that have very strict change control policies or are prevented from deploying custom solutions as in cloud based environments.

Since the solutions are only partially trusted and uploaded to a specific site collection there are limitations. Sandboxed solutions cannot access resources outside of the farm, access a database directly, call unmanaged code, access resources in a different site collection, or write data to the local server.

For any solution that fits cleanly into a single site collection, and does not need to reach out to resources outside of that boundary, sandbox solutions offer additional flexibility. It is also important to note that a sandbox solution can also be deployed as a farm solution giving administrators the option of deploying it either way.

Good candidates for sandbox solutions include:

• Most web parts

• Event receivers

• Most Application Pages

• List Definitions