One of the new (and exciting!) features in SharePoint 2010 is the client object model for development. You can now develop applications outside of the SharePoint server environment using a rich API instead of a services-based model. This is a big step forward in the development experience for SharePoint, as you now can develop on the client and return your results as recognizable SharePoint objects.
There are three (3) different object models:
- .NET
- Silverlight
- ECMAScript (Javascript)
Each object model requires that you add specific references in your project in Visual Studio 2010. For the .NET and Silverlight OMs, the DLLs are located in the [..]14ISAPI and [..]14TEMPLATESLAYOUTSClientBin directories, respectively. For the ECMAScript OM, you need to add a single Java library, /_layouts/sp.js.
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. Other differences are that the method signatures can be different, and the data value types can also differ between the object models.
Development using the client object models is slightly different than development with the SharePoint server object model. The main differences are:
- Client object models are centered on the ClientContext object
- ClientContext handles all communication with the SharePoint site
- Process is to “batch” commands and then send them to the SharePoint site
Sending commands to SharePoint is done with:
- ExecuteQuery()
- ExecuteQueryAsync(successCallback, failCallback)
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.
Once you have a ClientContext object instantiated, you can retrieve data from the SharePoint server. Look at the following code snippet:
ClientContext ctx = new ClientContext("http://intranet.wingtip.com");
Web web = ctx.Web;
ctx.Load(web, x => x.Title);
ctx.ExecuteQuery();
string webTitle = web.Title;
This snippet instantiates the ClientContext object, passing the SharePoint site as a parameter to the object constructor. We can then instantiate a Web (notice it is not SPWeb) object to reference the SharePoint site, and retrieve data from it. The snippet also uses a lamda expression to instruct the code to only return the title of the site to be returned (since Web objects are quite heavy, we may not want to incur that performance hit, if we are only interested in a subset of the data). The ExecuteQuery() command instructs the code to retrieve the specified data. Once returned, the code can directly access the data via object properties.
Creating objects on the client is simple, and is handled by creation objects. For example, to create an item on an existing list, look at the following snippet:
ClientContext ctx = new ClientContext("http://intranet.wingtip.com");
List announcementList = ctx.Web.Lists.GetByTitle("Announcements");
// create list item
ListItemCreationInformation newItem = new ListItemCreationInformation();
// add item to the list & get new item
ListItem newAnnouncement = announcementList.AddItem(newItem);
// update item
newAnnouncement["Title"] = "Now *this* is real COM!";
newAnnouncement.Update();
// send commands to server
ctx.ExecuteQuery();
In order to create an item in the Announcements list, we need to instantiate a ListItemCreationInformation object. We can then add this item to the list we want, and can add all the pertinent info we need for that list item (by calling the Update() method on the List object). Once we are ready to send our changes to the SharePoint site, we call ExecuteQuery() to send the commands to the server. Creating a new list would follow the same process, but we would use the ListCreationInformation object instead.
In conclusion, this article is only scratching the surface of what the client object models are capable of, but the potential to develop really cool and innovative solutions now exist outside of the server environment. Additional information can be found here:
http://blogs.msdn.com/ericwhite/archive/2009/11/20/using-the-sharepoint-2010-managed-client-object-model.aspx
http://msdn.microsoft.com/en-us/sharepoint/ee513152.aspx