Introducing the Sandbox

In earlier versions of Sharepoint, there were limited options for developing custom solutions to a Sharepoint enviroment. You should deploy essemplies either to the global assembly cache or to the Web application's bin folder within the Internet Information Services (IIS) file structure. You would deploy other resource, such as images, configuration files, user controls, and Sharepoint features, to the Sharepoint file structure (commonly referred to as the "Sharepoint root") on each server. In order to manage the installation, deployment, and retraction of these assemblies and resource over multiple servers, you would use a Sharepoint solution package (WSP). The solution package would...
The old approach works well, as long as you meet the following criteria:

1. You have server-side acesss to the Sharepoint farm
2. You are a member of the Farm administrators group
3. You care the confidence of the IT team.

What are the Sharepoint execution models?

In terms of execution models, there are two principal types of solutions in Sharepoint 2010: farm solutions and sandboxed solutions. Farm solutions can include components that run in a full-trust environment or components that rununder code access

Typical Scenarios for Sandboxed Solutions

Common scenarios for sandboxed solutions include the following:
• Data aggregation. For example, you might want to 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. 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. Imagine that 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 receiver classes to register the content type with the
library.


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 geocoding 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. Imagine, for instance, 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. 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. Let’s say you want to show a list of custom activities from your customer relationship management (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.