https://www.nothingbutsharepoint.com/sites/devwiki/articles/pages/understanding-the-sp2010-client-object-model.aspx
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 are:
1-Extend an existing client Windows forms application to interact with the SharePoint OM,
2-Build Silverlight components,
3-Build web parts which contain client side code like Ajax or Silverlight.
The Challenges in SharePoint 2007
The first challenge we faced in SharePoint 2007 was to extend an existing application which runs on the client side.
In order to utilize the SharePoint object model from the client application side 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 number of risks into the SharePoint farm.

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...and more importantly, which do not introduce a large amount of post backs to the server.
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 having to use SharePoint Web Services!!!
(The client side object model uses WCF internally, but the developer does not need to build new custom web services like they had to in SharePoint 2007)
How does the Client-Side Object Model work?
Lets evaluate the following diagram:
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 article), 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 don’t 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. As a developer you do not need to worry about the JSON, you only need to interact with the object model.
The SharePoint Foundation 2010 managed client model consists of Two Assemblies that contains five namespaces. All the Client OM DLL files combined are under 1mb in size where the server side Microsoft.SharePoint.dll is about 15mb in size.
There are 3 types of client object models:
1-.NET Client Object model
2-Silverlight Client Object model
3-ECMAScript Client Object model
1-.NET Client Object model:
This is used to extend Windows Form applications, services, WPF applications, console applications etc.
It consists 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 consists 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 consists of:
CUI.js (344 kb)
SP.js (381 kb)
SP.Core.js (13 kb)
SP.Ribbon.js (208 kb)
etc...
The JavaScript files are available as smaller compressed files for production use as well as a set of larger uncompressed files which can be used for debugging.
You will notice that Microsoft did a good job in providing the developer with objects which are close to the server OM which they are already familiar with.
There are however a few differences between the objects in the Client-Side Object models and the Server-side Object model:
Server OM
|
.Net Client OM & Silverlight Client OM
|
ECMAScript OM
|
Microsoft.SharePoint.SPContext
|
Microsoft.SharePoint.Client.ClientContext
|
SP.ClientContext
|
Microsoft.SharePoint.SPSite
|
Microsoft.SharePoint.Client.Site
|
SP.Site
|
Microsoft.SharePoint.SPWeb
|
Microsoft.SharePoint.Client.Web
|
SP.Web
|
Microsoft.SharePoint.SPList
|
Microsoft.SharePoint.Client.List
|
SP.List
|
Microsoft.SharePoint.SPListItem
|
Microsoft.SharePoint.Client.ListItem
|
SP.ListItem
|
Microsoft.SharePoint.SPField
|
Microsoft.SharePoint.Client.Field
|
SP.Field
|
Let’s build some simple code:
1. Create a new Visual Studio 2010 Console application
2. Add a references to:
Microsoft.SharePoint.Client.dll and
Microsoft.SharePoint.Client.Runtime.dll
3. Ensure your console app code look as follows:
01 | <span class = "ms-rteForeColor-8" > using System; |
02 | using Microsoft.SharePoint.Client; |
08 | Web site = clientContext.Web; |
09 | clientContext.Load(site); |
10 | clientContext.ExecuteQuery(); |
11 | Console.WriteLine( "Title: {0}" , site.Title); |
5. Press control+F5 and see your code execute.
Let’s analyse the code:
You inform the .NET 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.
The clientContext.Load(site) will inform the client object model about operations that you want to perform.
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 traffic occurs before then.
My first
Another Example:
1. Create a new Visual Studio 2010 Console application
2. Add a references to:
Microsoft.SharePoint.Client.dll and
Microsoft.SharePoint.Client.Runtime.dll
3. Ensure your console app code look as follows:
01 | <span class = "ms-rteForeColor-8" > using System; |
02 | using Microsoft.SharePoint.Client; |
08 | List list = clientContext.Web.Lists.GetByTitle( "Announcements" ); |
09 | CamlQuery camlQuery = new CamlQuery(); |
10 | camlQuery.ViewXml = "<View/>" ; |
11 | ListItemCollection listItems = list.GetItems(camlQuery); clientContext.Load(list); |
12 | clientContext.Load(listItems); |
13 | clientContext.ExecuteQuery(); |
14 | foreach (ListItem listItem in listItems) |
15 | Console.WriteLine( "Id: {0} Title: {1}" , listItem.Id, listItem[ "Title" ]); |
5. 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, isn’t it!
Authentication Modes:
.NET Client OM:
- Default is to authenticate users via their current Windows credentials (NTLM and Kerberos).
- Possible for you to define other authentication methods like Anonymous or Forms Authentication.
Silverlight Client OM:
ECMAScript Client OM:
- No need for additional authentication as Javascript already runs in an authenticated page.
Tips:
- Fiddler (freeware) is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet and is a great tool to help you monitor and debug the traffic between the client and SharePoint server (http://www.fiddler2.com).
- Building standalone Silverlight applications that connect to SharePoint sites is not supported.
- Client computer using the JavaScript object model must support the minimum set of requirements needed for ASP.NET AJAX and SharePoint 2010.
- Client object model does not provide any objects scoped higher than SPSite
- SharePoint administration related objects are not available in the Client OM.
Background
One of the coolest features of SharePoint 2010 is Client Object Model. You might already know that if we have to talk to SharePoint 2007 and don’t want to write the server side code then we call SharePoint Web Services. Now with SharePoint 2010 we can use Client Object Model to talk to SharePoint and the option of web services is still there. Once a wise man said, two options are always better than one.

How SharePoint Client Object Model Works
SharePoint Client Managed Object Model is a SharePoint API that runs on the client side. It converts the API calls made by the application, into XML request and sends it to the SharePoint server. On the server, the XML request is handled by a service called Client.svc where it translates the XML request in to appropriate Object Model calls (SharePoint Server Object Model) and gets the results. After getting the results, Client.svc translates them into JavaScript Object Notation (JSON) and sends back to the Client Managed Object Model. On the client side the JSON response is translated into ECMAScript objects for ECMAScript.
Writing the ECMAScript
- Create a list called Product and add few items in it.
- Create a test ASPX page in the Pages library.
- Add the Content Editor web part and add the following script in it.
01 | <script type= "text/javascript" > |
03 | ExecuteOrDelayUntilScriptLoaded(MainFunction, "sp.js" ); |
10 | function MainFunction() { |
11 | objContext = new SP.ClientContext.get_current(); |
12 | objWeb = objContext.get_web(); |
13 | objList = objWeb.get_lists().getByTitle( "Product" ); |
15 | objContext.load(objList); |
17 | objContext.executeQueryAsync(Function.createDelegate( this , this .onSuccess), Function.createDelegate( this , this .onFail)); |
20 | function onSuccess(sender, args) { |
21 | alert( 'Item Count: ' + objList.get_itemCount()); |
24 | function onFail(sender, args) { |
25 | alert( 'Some error has occured.' ); |
Explanation
To load the Java script Client Object Model, we have to call ExecuteOrDelayUntilScriptLoaded(Func, "sp.js"). This function takes the name of the function that need to be executed as a main function and will load the SP.js file, which is the core of Client Object Model. We have to load the current context in order to play with the site content by SP.ClientContext and then get the current site by calling get_web() function of current context. After getting the current site we call getByTitle to get the Product list and then we loaded that list. Note that we are not loading all the objects but only the list. Loading all the objects will cause delay and performance issues. We are loading the list asynchronously and if the call is successful OnSuccess()will be called and if the call failes OnFail() will be called.
Conclusion
ECMAScript is a java script based client side scripting language which is now supported in SharePoint 2010 and can be used to access Client Object Model. Users can write ECMAScript in an ASPX page for SharePoint 2010 sites and can manipulate the SharePoint content without even touching the Visual Studio (or SharePoint Designer) and getting involved in the complexities of the web services.