Understanding client object model fundamentals

SharePoint 2010 introduced the CSOM as a way to program against a Windows Communication Foundation (WCF) endpoint in SharePoint by using a style that mimicked server-side API development. Prior to the introduction of CSOM, SharePoint developers had only a limited set of web services available for use from client-side code. With the introduction of CSOM, developers had a way to access a significant portion of core SharePoint functionality from C# (called the “managed” client object model), JavaScript, and Silverlight. 

Understanding client object model fundamentals

The managed and JavaScript client object models are maintained in separate libraries, which are located under the SharePoint system directory. The managed client object model is contained in the assemblies Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.ClientRuntime.dll, which can be found in the ISAPI folder. The JavaScript client object model is contained in the library sp.js, which is located in the LAYOUTS folder. Although each of the models provides a different programming interface, each interacts with SharePoint through a WCF service named Client.svc, which is located in the ISAPI directory. Figure 1 shows a basic architectural diagram for the client object models.
In SharePoint 2013, CSOM has been greatly expanded to include functionality from workloads outside of SharePoint Foundation. Using CSOM, app developers now have client-side access to Enterprise Search, Business Connectivity Services, Managed Metadata, Social, and much more. This additional functionality is made available through separate assemblies and libraries that can be referenced in your apps.

image: http://tutorial.programming4.us/image/1411/Working%20with%20the%20CSOM_1.jpg

Figure 1. The client object model provides a programmatic interface to make web service calls against SharePoint by passing in an XML request and receiving a JSON response.

Each of the object models presents an object interface in front of a service proxy. Developers write client-side code using the object model, but the operations are batched and sent as a single XML request to the Client.svc service. When the XML request is received, the Client.svc service makes calls to the server-side object model on behalf of the client. The results of the server-side calls are then sent back to the calling client in the form of a JavaScript Object Notation (JSON) object.

Understanding contexts

Much like the standard code you write against the server-side object model, CSOM requires a starting point in the form of a context object. The context object provides an entry point into the associated API that can be used to gain access to other objects. Once you have access to the objects, you can interact with the scalar properties of the object freely (for example, Name, Title, Url, and so on). Example 1 shows how to create a context in each of the models and return an object representing a site collection. After the site collection object is returned, the Url property is examined.

Example . Creating contexts

//Managed Client Object Model
string appWebUrl = Page.Request["SPAppWebUrl"];
using (ClientContext ctx = new ClientContext(appWebUrl))
{
    Site siteCollection = ctx.Site;
    ctx.Load(siteCollection);
    ctx.ExecuteQuery();
    string url = siteCollection.Url;
}

//JavaScript Client Object Model
var siteCollection;
var ctx = new SP.ClientContext.get_current();
siteCollection = ctx.get_site();
ctx.load(site);
ctx.executeQueryAsync(success, failure);

function success() {
    string url = siteCollection.get_url();
}
function failure() {
    alert("Failure!");
}

The ClientContext class in the managed object model inherits from the ClientContextRuntime class. Using the ClientContext class, you can get a valid runtime context by passing in the URL of a site. In Example 1, the URL of the app web is retrieved from the SPAppWebUrl query string parameter. This URL is always available to the remote web and can be used to create a client context for scenarios in which the SharePoint app is using the “internal” security principal.
The SP.ClientContext object in the JavaScript client object model inherits from the SP.ClientContext Runtime object and provides equivalent functionality to the ClientContext class found in the managed client object model. Like the managed model, you can get a runtime context in the JavaScript model by using the SP.ClientContext class and passing a URL. In Example 1, the context is created by using the get_current method, which returns a client context for the app web.

Loading and executing operations

The ClientContextRuntime class used by the managed client defines two methods for loading objects: Load and LoadQuery. You use these load methods to designate objects that should be retrieved from the server. The Load method specifies an object or collection to retrieve, whereas you use the Load Query method to return collections of objects by using a Language-Integrated Query (LINQ) request.
Executing the Load or LoadQuery method does not cause the client to communicate with the server. Instead, it adds the load operation to a batch that will be executed on the server. In fact, you can execute multiple load methods (as well as other operations) before calling the server. Each operation is batched waiting for your code to initiate communication with server. To execute the batched operations, your code must call the ExecuteQuery method in managed code or the Execute QueryAsync method in JavaScript. The ExecuteQuery method creates an XML request and passes it to the Client.svc service synchronously. The ExecuteQueryAsync method sends the request asynchronously. Designated success and failure callback methods receive notification when the asynchronous batch operation is complete.
The sample code in Example 1 uses the Load method to request an object representing the current site collection. After an object is returned, you can generally access any of the scalar properties associated with the object. In cases for which you do not want to return all of the scalar properties for a given object, you can designate the properties to return. In the managed object, properties are designated by providing a series of lambda expressions. In the JavaScript object model, properties are designated by name. This technique helps to minimize the amount of data sent between the client and server. The following code shows how to request only the Title and ServerRelativeUrl properties for a site collection object:

//Managed CSOM references properties via lambda expressions
ctx.Load(site, s=>s.Title, s=>s.ServerRelativeUrl);

//JavaScript CSOM references properties by name
ctx.Load(site, "Title", "ServerRelativeUrl");

Read more at http://tutorial.wmlcloud.com/windows_server/sharepoint-2013---working-with-the-csom-(part-1)---understanding-client-object-model-fundamentals.aspx#FHgS2tvTXDctHk8z.99