Client Object Model:SharePoint 2010

The Client Object Model is a new object model introduced in SharePoint 2010 which is aimed at making things easier for the developer when developing client-side applications for SharePoint 2010. Client Object Model can run on the client machines (Where SharePoint is not installed) and communicate with the SharePoint server remotely.

In my previous post, i already shared all types of client object model examples.

Why Client Object Model comes into the picture? Are there any specialties of them?

The main started points to think by SharePoint team are as follows.

1. Is it really necessary to have SharePoint installed on server for SharePoint development? - Yes, in SharePoint 2007 you have to install SharePoint on the server to write code and test it. 
2. What is the advantage of writing more web services to serve what the clients are looking for? - This is completely not a feasible solution to give or expose web services for each and every single requirement to get and manipulate data. It has plenty of limitations and if Microsoft exposes 500 web services and you didn't find what you really need and they are just waste. Instead write whatever you want and use them.
3. The great thinking and beautiful solution to the people who don't allow server side coding in the SharePoint sites is ECMAScript client OM. You can create a simple JavaScript file and deploy into the server to get what you needed. As we know, most of the clients don't allow server side coding but they want something to be developed. In SharePoint 2007 it's very difficult to get this job done. But now in SP 2010 very easy.

So, these things take into high priority and make them to come up with a great solution in the form of Client Object Model. The great advantage of it is completely looks [Syntax] like the SharePoint Object Model. So, nothing new for the developers and no confusion. In fact very simple to manage and write code.

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.

When a request is made to access a page, only the files required to render the page are downloaded to the client. For example, if your programs use only the SP.CORE.js script, you can specify that only this script is downloaded to the client. This is a huge performance boost from earlier version of SharePoint which downloaded the complete set of core JavaScript files when a page was accessed. If the script has references to any other files, they are also automatically downloaded to the client. 

  

It is important to be aware that you control when the SharePoint Foundation 2010 managed client object model starts to send the XML to the server and receives the JSON back from the server.

The SharePoint Foundation 2010 managed client object model bundles method calls and sends a request to the server. As part of this process, before you start the interaction with the server, you must explicitly specify what content that you want to retrieve from the server. This is the biggest difference between the SharePoint Foundation 2010 managed client object model and the SharePoint Foundation 2010 object model.

ExecuteQuery method

The call to the ExecuteQuery method causes the SharePoint Foundation 2010 managed client object model to send the request to the server. There is no network traffic until the application calls the ExecuteQuery method.

An important point to make about this example is that the call to the Load method does not actually load anything. Instead, it informs the client object model that when the application calls the ExecuteQuery method, you want to load the property values of the siteCollection object.

Client.svc is an internal WCF service; it is reserved for SharePoint usage and is not intended to be used directly in client code. If you attempt to add a service reference to this service, no proxy will be generated. Internally, the Client.svc leverages the server-side object model to handle all client requests and return a JSON response.

Three new client APIs:

With the Client Object Model, Microsoft has introduced a set of new APIs to work with to ease the daily tasks of developers.

• .NET Managed Applications (using the .NET CLR)
• Silverlight Applications
• ECMAScript (JavaScript, JScript)

The client APIs provide you as a developer with a subset of the Microsoft.SharePoint namespace which is based on the server-side object model.

Naming conventions:

As a small side-note I would like to mention that the objects you are comfortable with calling “SPWeb”, “SPSite”, “SPList” and so on are now named “Web”, “Site”, “List”.

So to conclude the naming convention, the “SP” in the objects has been dropped. Easy enough to remember, right?

The main assembly’s references for the client object models are:

·         .NET Managed Applications

o   Microsoft.SharePoint.Client.Runtime.dll (Located in:
" C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI").

• Silverlight Applications
• Microsoft.SharePoint.Client.Silverlight.dll and Microsoft.SharePoint.Client.Silverlight.Runtime.dll (Located in: "14\TEMPLATE\LAYOUTS\ClientBin").

•  ECMAScript Applications
• SP.js (Located in: “14\TEMPLATE\LAYOUTS”).

Remembering points:

1.      There are a few differences between the object models provided, with the most significant one being that both the .NET and Silverlight OMs allow communication with any SharePoint site, while the ECMAScript OM only allows communication with the originating SharePoint site. The reason for this is that JavaScript can have cross-site scripting controls, and allowing communication with other SharePoint sites is a large security risk. 

2.      There are couple of important points to remember about “ClientContext”

1. SharePoint client object model uses client context object that is operational bridge head between your code and data in SharePoint.
2. Context gathers all queries and modifications and completes requested operations when ExecuteQuery() method is called.

3.      The ExecuteQuery () method is used by the .NET client OM, and is a synchronous call. ExecuteQueryAsync () is used by both the Silverlight and ECMAScript OMs, and is an asynchronous call. Notice that this method takes two callback parameters, which specify methods to execute if the commands being sent (and processed) succeed or fail.

4.      While using ECMAScript Client OM, if your code modifies SharePoint content, you need to add a FormDigest control inside your page.

5.      The ExecuteQuery () method is invoked asynchronously passing two functions: onSuccess and OnFailed which will be called on success and fail correspondingly.

Microsoft released an installer, to install the SharePoint client dll's on a non-SharePoint pc. Refer to get to know more on it here. 

    SharePoint Client Object Model Redistributable Released