Understanding the Client Object Model
Figure 1. Client Object Model Architecture
Objects supported by the Client Object Model
One of the first questions that comes up when talking about the Client Object Model is, “What can you do with it?” Again, understanding how the Client Object Model works will help you appreciate its capabilities and limitations. The Client Object Model
proxies are based on the Microsoft.SharePoint.dll. Right away this establishes what you can do to this API. The Microsoft.SharePoint API supports the most common objects, such as sites, webs, content types, lists, folders, navigations, and workflows. Obviously, this is not an exhaustive list. So, how do you find out if a particular object is supported in the Client Object Model? Fortunately, the help documentation for SharePoint 2010 is very good, and you can find the complete list by looking at the Microsoft.SharePoint.Client Namespace on MSDN.
Another way to find out if a particular object is supported is to look at the attributes on the Microsoft.SharePoint API. Remember that the client proxies are created from the server API (Microsoft.SharePoint Namespace). The tool knows what to put in the client proxies by looking for the attribute named ClientCallableTypeAttribute. The Client Object Model does not require a reference to the server assemblies.
The ClientCallableTypeAttribute also specifies the name to call the object in the proxy. This brings up another important point about the Client Object Model. The names in the Client Object Model have been cleaned up a little by removing the ‘sp’ from the beginning of most of the objects. But knowing how the Client Object Model is implemented enables you to look in the help documentation and see what the server object is and what the client object is called. For example, open the help page for the SPSite class. In theSyntax section at the top of the help topic, you can see the ClientCallableTypeAttribute and the name that it will be called in the proxy classes.