Note
This chapter is taken from SharePoint 2010 Business Application Development Blueprints (Preface) by Mike Oryszak. At the time of publication, this chapter is taken from an exciting new Packt title which is yet to be published.
SharePoint provides a robust platform that contains many services from which we can create business solutions. While many solutions can be configured using the included features, it is often necessary to develop customizations in order to meet all of the business requirements for a project. Customizations can come in many forms that range in complexity from simple visualizations in web part displays, custom forms, and timer jobs , all the way to a custom service application that extends the application to provide fully packaged solutions.
These customizations can be created using a number of different techniques so it is important to understand the strengths and limitations of each of the development paths. It is also important to understand the development tools that are available and what they can produce.
In the sections that follow you will find a brief overview of the different customization options that are available, tools that can be used to create them, as well as some additional considerations when choosing a development path.
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.
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 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