SP2010 Basics: Client Object Model

This post is part of the series which I will share in order to help you understand the new architecture of SharePoint 2010 and the impact thereof on you as developer.

This week I had the opportunity to be a speaker at the AvePoint Interactive Theater at Teched Africa 2010.

I decided to present an understanding of the SharePoint 2010 Managed Client Object Model. This is an introduction to how the Client Object model works, the benefits it brings and some very important considerations you have make.

So...lets get cracking...

The Standard SharePoint 2007 Implementation
This diagram shows the standard communication between a SharePoint client browser and the server in a non customized environment.
You can see that there is nothing special required on the client side. Simple comms to the server and then some execution there.

What do we want to achieve?
Sometimes we want to extend SharePoint by adding functionality which will execute on the client-side. This means we want some mechanism to execute code on the client-side but then still interact with SharePoint data and functionality which reside on the server.
Examples of this will be:
1-Building Silverlight components,
2-Build web parts which contains client side code like ajax or silverlight,
3-Extend an existing Windows forms application which contains client-side code.

The Challenges in SharePoint 2007
The first challenge we faced in SharePoint 2007 was that if we wanted to extend an existing application which runs on the client side. In order to utilize SharePoint you had to use the native SharePoint Web Services or build new custom web services which will be hosted on the SharePoint server. Remember that custom web services will use the server object model. Deploying custom web services onto the server creates an administrative overhead and introduces a risk.

The second challenge is in building silverlight applications which execute client-side.

So it is very obvious that we needed some mechanism to build client-side code which has an awareness and access to the SharePoint Server Object Model.

Microsoft helped solve this problem for us by introducing the SharePoint 2010 Client Side Object Model. Now we have a mechanism to extend SharePoint functionality through client-side code..without using SharePoint Web Services !!!

How does the Client-Side Object Model work?

From the diagram you will see that we have the client on the left and the server on the right. The server contains the SharePoint Databases and the Server-side Object model.
Between the server and client is a new WCF service called Client.svc
When you reference the client-side object model in your code (example later in this post) , the internal proxy class takes care of sending requests and review responses via the WCF Service.

The very important thing to notice here is that we dont want to send requests to the server and get a response for almost every line of code we execute. So how it is designed to work is that in your code you will construct the objects and execute standard SharePoint OM functions. The objects will be empty structures without properties and without data, and the functions will not execute right away.
Then at logical points you bundle everything together and send it to the server for processing. The server will then unpack your bundled code and execute it in the correct order and return JSON to your client-side. Your objects will then be populated with data and properties and you can carry on executing more code. The important concept to understand is that you bundle empty objects together and send to the server when ready for processing.

The SharePoint Foundation 2010 managed client model consist of Two Assemblies that contains five namespaces.

There are 3 types of client object models.
1-Managed Client Object model
2-Silverlight Client Object model
3-ECMAScript Client Object model

1-Managed Client Object model:
This is used to extend Windows Form applications, services, WPF applications, console applications etc.
It consist of Microsoft.SharePoint.Client.dll (282 kb) and
Microsoft.SharePoint.Client.Runtime.dll (146 kb)

2-Silverlight Client Object model:
This is used to Silverlight Applications.
It consist of Microsoft.SharePoint.Client.dll (282 kb) and
Microsoft.SharePoint.Client.Runtime.dll (146 kb)

3-ECMAScript Client Object model:
JavaScript in our SharePoint user interface.
It consist of:
CUI.js (344 kb)
SP.js (381 kb)
SP.Core.js (13 kb)
SP.Ribbon.js (208 kb)
etc...

You will notice that there are a few differences between the objects in the Client-Side Object model and the Server-side Object model:

Lets build some simple code:
Create a new Visual Studio 2010 Console application
Add a references to:
Microsoft.SharePoint.Client.dll and
Microsoft.SharePoint.Client.Runtime.dll
ensure your console app code look as follows:

using System;
using Microsoft.SharePoint.Client;
class DisplayWebTitle
{
static void Main()
{
 ClientContext clientContext = new ClientContext("http://ltp-21:17819/");
 Web site = clientContext.Web;
 clientContext.Load(site);
 clientContext.ExecuteQuery();
 Console.WriteLine("Title: {0}", site.Title);
}
}

Press control+F5 and see your code execute.

Lets analyze the code:
You inform the managed client OM about the operations that you want to take.
This includes accessing the values of properties of objects (for example, objects of the List class, ListItem class, and Web class), CAML queries that you want to run, and objects such as ListItem objects that you want to insert, update or delete.
Then you call the ExecuteQuery method.
Only when you call the ExecuteQuery will the objects be bundled up and sent to the server for processing.
No network traffice occurs before then.

Another Example:
Create a new Visual Studio 2010 Console application
Add a references to:
Microsoft.SharePoint.Client.dll and
Microsoft.SharePoint.Client.Runtime.dll
ensure your console app code look as follows:

using System;
using Microsoft.SharePoint.Client;
class Program
{
  static void Main()
  {
 ClientContext clientContext = new ClientContext("http://ltp-21:17819/");
 List list = clientContext.Web.Lists.GetByTitle("Announcements");
 CamlQuery camlQuery = new CamlQuery();
 camlQuery.ViewXml = "<View/>";
 ListItemCollection listItems = list.GetItems(camlQuery);  clientContext.Load(list);
 clientContext.Load(listItems);
 clientContext.ExecuteQuery();
 foreach (ListItem listItem in listItems)
  Console.WriteLine("Id: {0} Title: {1}", listItem.Id,  listItem["Title"]);
  }
}

Press control+F5 and see your code execute.

Again, the code will be bundled up and only be sent to the server for processing when the .ExecuteQuery() run.
This means that although you called the list.GetItems the CAML did not execute at that time.
When you call the .ExecuteQuery(), the server will receive your code, unpack it and execute it in the correct sequence and return the objects populated with data and properties.... all processed on the server side... and ready to be further used on the client-side !!!!

Amazing, isnt it ! Well I hope this gives you a nice overview of the Client Side Object model in SharePoint 2010.

Have Fun !