SharePoint 2010 Client Object Model Development

SharePoint 2010 provides a new client object model that enables you to create SharePoint solutions that run remotely from the SharePoint server farm. For example, the client object model enables you to consume and manipulate SharePoint data in Windows Forms applications, Windows Presentation Framework application, console applications, Silverlight applications, and ASP.NET Web applications.

There are three new client-side APIs that allow SharePoint developers to use and interact with the SharePoint object model from the client:

• .Net Managed Applications - Writing a custom application for your organization that uses .Net? You can now interact with a limited version of the SharePoint object model directly from the client.
• Silverlight Applications - The lines between client applications and browser-based applications are blurring. You can now use a limited version of the SharePoint object model directly from a SilverLight client.
• ECMAScript (JavaScript) - Writing a custom web application that isn't using the SharePoint architecture? Just copy some .js files into your development library and the SharePoint object model is there for you to use.

Client OM Architecture

Before getting to actual usage we'll take a brief look at the architecture of the Client Object Model to understand how it functions.

As can be seen in the above diagram all versions of the Client OM go through the WCF Web Service namedClient.svc. This Web Service is located, along with all other SharePoint Web Services, in the folder [SharePoint Root]\ISAPI. The Client OM is responsible for packaging any requests into XML and calling the Web Server, however, when this call takes place is controlled by the developer as you will see. The response from the Client.svc Web Service is sent as JSON and the Client OM is responsible for transforming this into appropriate objects for use in the environment the call was made from.

Here are a few highlights of some of the real distinctions between these three object models:

.Net Managed Applications

• .Net 3.5 or higher
• Synchronous
• Absolute URL for context
• Cannot use Current property for context
• Microsoft.SharePoint.Client is the core namespace
• There are two development dlls: Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll.
• Path to get DLL's: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI

SilverLight

• SilverLight 2.0 and above
• Synchronous or Asynchronous
• Absolute URL for context
• Can use Current property for context
• Microsoft.SharePoint.Client is the core namespace
• There are two development dlls: Microsoft.SharePoint.Client.Silverlight.dll and Microsoft.SharePoint.Client.Silverlight.Runtime.dll.
• Path to get DLL's: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Templates\Layouts\ClientBin\

ECMAScript

• Asynchronous
• Absolute, relative, or no URL for context
• Can use Current property for context
• SP is the core namespace
• There are several .js files needed for development. Here are a few of them: SP.js, SP.Core.js, SP.Ribbon.js, SP.Runtime.js
• Path to get DLL's: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS

The client object model follows an SQL-like process flow:

• Retrieve a client context object
• Use the object model to specify an object to retrieve
• Load the object to return a specific object collection or data
• Execute a query to obtain the object

Here is some sample code taken directly from the SDK that demonstrates how to retrieve the title of a website:

using System;
using Microsoft.SharePoint.Client;

namespace Microsoft.SDK.SharePointServices.Samples
{
      class UsingClientContext
     {
           static void Main()
           {
               ClientContext clientContext = new ClientContext("http://MyServer/sites/MySiteCollection");
               Web oWebsite = clientContext.Web;
               clientContext.Load(oWebsite);
               clientContext.ExecuteQuery();
               Console.WriteLine(oWebsite.Title);
            }
     }
}

Web Services
Traditionally, if you wanted to interact with SharePoint from a client, you had to use Web Services (either Microsoft provided or custom). Microsoft is strongly encouraging developers to use the client object model now, instead. Here is a direct quote from the SDK:

“These APIs are still supported for backward compatibility with Web service clients. For reasons of both performance and ease, we recommend that you use either the client object model or the ADO.NET Data Services Framework"

Conclusion
The client object model provides useful APIs for interacting with SharePoint from the client. I imagine that support for these APIs will only grow as SharePoint continues to grow. It may be time for your organization to reevaluate how you use Web Services and how you provide a rich, interactive experience for your users.