Saturday, November 7, 2009

SharePoint 2010 Client Object Model Development

I spent some time reading the SDK on the Managed Client Object Model in SharePoint 2010. I thought I would distill some of the information for those of you that don't have time to read the entire object model SDK.

Resources: Managed Client Object Model SDK

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.
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
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
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
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.

No comments:

Post a Comment