In SharePoint 2010, you'll notice an area that was given great attention. It's now easier to work with SharePoint data in multiple scenarios. In SharePoint Foundation 2010 (SPF2010), Microsoft added LINQ support to help you create solutions that run on SharePoint servers. By introducing a RESTful service that exposes all lists and their contents, Microsoft also addressed the challenge of working with SharePoint data coming from external applications. Thankfully, Microsoft didn't stop there.
With every release of SharePoint, customers consistently requested new Web services. The latest release of SharePoint contains a vastly reworked user interface (UI) that dramatically reduces the number of page refreshes. Microsoft needed something new to satisfy its own demands for the improved UI and to provide a better and more robust platform for creating solutions that will run off SharePoint servers. This has been achieved with the client object model, which consists of three major components (.NET, Silverlight, and ECMAScript) that you can use in various situations.
The three implementations of the client object model share striking similarities. As I'll explain in this article, all three work the same way and have only subtle differences. The first question you might ask about the client object model is “What can or can’t I do with it?” Generally speaking, you can work and perform the most common actions on SharePoint site collections (e.g., reading and writing data on lists, creating lists, managing user permissions), as well as work with Web Parts on Web Part pages.
ClientContext: The Client Object Model Hub
All three client object models have a single center of gravity: the ClientContext object. The ClientContext object establishes a connection from the client to the remote SharePoint site, manages authentication, and handles the execution of code on the server queued by the client. Creating an instance of the ClientContext object is the first step in any client object model solution, as shown in Figure 1. Note that this object implements the IDisposable interface and thus should be wrapped up in a using() statement or disposed of properly. After you've created a ClientContext object, you can leverage its power to work with data in SharePoint lists and to use the provided support structures such as data CRUD operations, exception handling, conditional scopes, and authentication.
Data CRUD operations: Once a ClientContext object has been established with the server, the next thing you'll want to do is perform some sort of CRUD (create, read, update, or delete) operation on SharePoint lists.
As previously mentioned, the ClientContext object handles all communication between the client and the SharePoint site. This communication is done by queuing commands to run on the server and then executing them as a batch. This model gives you full control over how chatty your application will be with the server.