Examples and Scenarios

Before you take a detailed look at the functionality and constraints of each execution model, it is worth taking some time to review some high-level examples that illustrate when each model might be appropriate. There are several factors that should influence your choice of execution model. In some cases, the decision may be made for you. If your code will be deployed to a shared or hosted environment, you may well be limited to the deployment of sandboxed solutions. If you are designing a third-party application, targeting the sandbox environment could make your product viable to a wider audience. In other cases, despite the inherent benefits to the overall stability, security, and performance of the farm as a whole, sandboxed solutions may not allow you to do everything you need to. The intended scope of your solution is another important factor—sandboxed solutions are constrained to a single site collection, bin/CAS solutions are restricted in scope to a single Web application, and full-trust solutions are available to the entire server farm.

Typical Scenarios for Farm Solutions

You can use the full trust farm solution approach to deploy absolutely any combination of functionality and resources from the entire spectrum of SharePoint development. However, that does not mean that the full-trust model is always the best choice. When you deploy a solution that uses the full-trust execution model, you lose all the safeguards that are offered by the sandbox and hybrid approaches. Typically, you might choose to deploy a full-trust farm solution when the functionality you need is not available in the sandbox environment and the additional effort of building a hybrid solution is not justified. You might also consider full-trust solutions for high volume, public-facing sites where the performance impact of using a sandboxed solution is unacceptable.

When you consider a bin/CAS deployment, remember that code access security policies can be difficult to get right and difficult to maintain. With the introduction of the sandbox environment, the combination of sandboxed solutions with full-trust components where necessary is preferred to the use of the bin/CAS approach in most cases. However, there are still some circumstances where you may want to consider using the bin/CAS execution model. For example, if you have a high volume site and you want to take advantage of granular security for your application, the bin/CAS model might meet your requirements. If you invest a great deal of time in Web Part development, and the lack of support for Visual Web Parts within the sandbox causes an unacceptable decrease in productivity, the bin/CAS model could offer an alternative solution. The bin/CAS approach cannot be used to run feature receivers, coded workflow activities, timer jobs, or service applications. These components must be deployed to the global assembly cache.

Common scenarios for full-trust farm solutions include the following:

• Asynchronous timer jobs for large, regular batch operations. For example, you might want to aggregate data from lists and sites on different site collections. Alternatively, you might want to run a bulk import or export of external data on a daily or weekly basis.
• Fully coded workflows or activities. You can model many business processes by creating your own custom workflow activities and consuming these activities from declarative workflows. However, in some cases, only a fully coded workflow will provide the functionality you need, particularly if you require complex or parallel branching logic. For example, suppose you implement a process to create swipe cards for secure access. The workflow must connect to an external security system to create the user record and request card production. You might use a fully coded workflow to support a parallel approval process with the Human Resources department and the security team.

Typical Scenarios for Sandboxed Solutions

In many cases, the sandbox execution model may be the only option available to you. This is particularly likely if you want to deploy a solution to a highly regulated environment, such as a shared or hosted deployment, or if your organization cannot justify the management costs of an environment that allows full-trust solutions. However, there are also many scenarios in which the sandbox execution model might be your preferred approach, regardless of the options available to you. In addition to the farm-wide benefits of stability, security, performance, and monitoring, sandboxed solutions offer benefits to solution developers. For example, you can upload your sandboxed solutions through a Web interface and without the involvement of the IT team; this enables hassle-free deployments and faster development iterations. If the capabilities of the sandbox environment meet the requirements of your application, the sandbox execution model will often be an attractive choice.

Common scenarios for sandboxed solutions include the following:

• Data aggregation. For example, you might want create a Web Part or a Silverlight control that shows a summary of all tasks assigned to the current user from across the site collection or that aggregates sales data from individual team sites.
• Data capture. For example, suppose you are responsible for organizing and posting job vacancies at your organization. You might deploy a content type and an InfoPath form to collect and organize the information. You could also include a declarative workflow to manage the process through the received, approved, and posted phases.
• Document management. For example, suppose you need to create a document repository for resumes. You might create a solution package that includes a document template and a content type. You deploy the document template to a document library and you include feature receivers classes to register the content type with the library.

Typical Scenarios for Hybrid Solutions

Hybrid approaches can offer an attractive choice when the sandbox execution model alone does not provide all the capabilities that you need. You can use a hybrid approach to minimize the amount of full-trust code in your solution, both to maximize the performance and stability benefits you gain from the sandbox environment and to limit the management and review costs associated with the deployment of full-trust code.

Hybrid approaches also enable you to make additional functionality available to sandboxed solution developers across your organization. For example, you could develop and deploy a full-trust proxy that provides logging functionality. Other developers can use your full-trust proxy in sandboxed solutions, from any site collection, without exceeding the limitations of the sandbox environment.

Common scenarios for hybrid approaches include the following:

• Interaction with external services. For example, suppose you create a sandboxed solution that tracks help desk requests from external customers. Your solution might use a full-trust proxy to submit each customer's location details to a geo-coding service. The geo-coding service returns a latitude and longitude, which your sandboxed solution can use to calculate the nearest available engineer for each customer.
• Full trust workflow activities. For example, suppose you want to extend the job postings data capture example from the sandbox scenarios. You might create and deploy a full-trust workflow activity that takes the data from a posting form and then uses a Web service to publish the information to an external job board Web site. You can consume this workflow activity from the declarative workflow within your sandboxed solution.
• Extension of sandbox capabilities. For example, suppose you want to allow sandboxed solution developers to use personalization. You might create a full-trust proxy to expose properties from the profile store. Similarly, you might create proxies to enable sandboxed solution developers to use logging functionality or read configuration settings from the farm-scoped property bag.
• Integration with business data. For example, suppose you want to show a list of custom activities from your CRM system alongside a proposal workspace in SharePoint 2010. You could create an external content type to enable SharePoint solutions to interact with the CRM data. External content types are full-trust components. Within the sandboxed solution, you could create an external list that binds to the CRM external content type and enables you to query customer data.

How Does My Execution Logic Affect My Choice of Model?

Before you make design decisions about how to build a SharePoint application, it is important to understand how various SharePoint components execute their logic. First, knowing where your logic will execute can provide a useful context when you choose an implementation strategy. The following table maps different approaches to execution logic to the actual processes in which they execute.

SharePoint Components and Where Execution Happens

	IIS worker process	Sandbox worker processes	Timer job process	Service application processes
Declarative components
Web Parts		*
Web pages
Event receivers		*
Coded workflow activities		**
Full-trust assemblies
Fully coded workflows
Timer jobs
Service applications

*Restrictions apply; see text for details.

**SharePoint 2010 provides a wrapper activity that can call custom code in the sandbox. See text for details.

Note

Typically, workflows run in the IIS worker process when they are first initiated. After rehydration, they execute within the same process as the event that triggered the rehydration. For example, if there is a timed delay in the workflow, the workflow will be restarted from the timer process when the timer fires. If an approval causes the workflow to rehydrate, the workflow runs in the IIS worker process where the approval was received from the user. In some circumstances, workflow activities may also run in the sandbox worker proxy process (for example, if the sandbox code creates an item in a list that causes a workflow to run).

In addition to understanding where logic executes, it is important to know which execution logic patterns are supported by each execution model. The following table shows which execution models you can use with different execution logic patterns.

SharePoint Components and Supported Execution Models

	Sandboxed solution	Hybrid solution	Full-trust farm solution
Declarative components
Web Parts	*
Content pages
Application pages
Event receivers	*
Coded workflow activities	*
Full-trust assemblies
Fully coded workflows
Timer jobs
Service applications

*Restrictions apply; see text for details.

Some of these execution logic patterns are subject to restrictions when they run within a sandboxed solution. Visual Web Parts cannot be used in the sandbox without employing a workaround, because this would require the deployment of .ascx files to the SharePoint root on the server. Web Parts that run within the sandbox cannot use user controls for the same reason. Event receivers that run within the sandbox are limited to events that occur within the boundaries of the site collection, and they can only be registered declaratively.

Full-trust coded workflow activities can only be used within sandboxed solutions when they are consumed by a declarative workflow. You can also create sandbox code that is invoked by a wrapper workflow activity provided by SharePoint. For more information, see Sandboxed Solutions.