Help
The server-side object model for SharePoint has long been sophisticated and fully-functional. In fact, there is nothing that can be done in the browser that cannot be done through the server-side object model. When it comes to accessing SharePoint using rich clients, however, there has historically been a large deficit in functionality. In previous versions of SharePoint, client-side programmability was largely accomplished through a set of web services provided by SharePoint. These web services exposed basic functions for interacting with lists, performing searches, reading profile data, and the like. However, the scope of these web services was easily less than a third of the functionality available in the server-side object model. In response, many developers resorted to creating custom web services that wrapped the server-side object model, but this approach never yielded a complete programming model. As a result, customers have consistently requested improved client-side programmability for future versions of SharePoint.
SharePoint 2010 takes a dramatically new approach to client-side programmability by introducing three new client-side object models: Managed client, Silverlight, and Javascript. Each of the three object models provides an object interface to SharePoint functionality that is based on the objects available in the Microsoft.SharePoint namespace. This approach provides a development experience that is vastly superior to the web service model utilized in previous versions of SharePoint. While none of the models is fully equivalent to the server-side model, they are equivalent to each other so you can leverage your knowledge of one model into another.
Along with new client object models, SharePoint 2010 also introduces a new web service interface that utilizes WCF Data Services. This new interface is primarily used for querying lists from the client. The main advantage of WCF Data Services over the client object models is that it provides an object-relational mapping (ORM) layer over the lists and items so that they are strongly-typed in code. You should think of the WCF Data Services interface as a complement to the client object models, and you will often use them together in solutions.
Understanding Client Object Model Fundamentals
The three client object models are maintained in separate libraries, which are located under the 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 Silverlight client object model is contained in the assemblies Microsoft.SharePoint.Client.Silverlight.dll and Microsoft.SharePoint.Client.Silverlight.Runtime.dll which are located in the LAYOUTS\ClientBin folder. The Javascript client object model is contained in the library SP.js, which is located in the LAYOUTS folder. While each of the models provides a different programming interface, each interacts with SharePoint through a Windows Communication Foundation (WCF) service named Client.svc, which is located in the ISAPI directory. The following figure shows a basic architectural diagram for the client object models.
Each of the three 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.
The client object models focus on functionality for objects at and below the site collection level. This focus is sensible because the majority of client-side programming is targeted at improving the end-user experience. This focus also makes the associated libraries smaller, which is particularly important when scripts must be downloaded for the Javascript model. Additionally, great care has been taken to ensure that the three models return objects that behave similarly. This means that if you know how to write code against one of the models, you can easily port that code to either of the other two models. The following table lists some of the main objects that are supported by each model alongside the equivalent object from the server-side model.
