SharePoint 2010 Data : Access using .NET Client Object Model

On MSDN, a new article along with video is now available for "Accessing SharePoint 2010 Data with the .NET Client
Object Model" provided by Andrew Connell.

abstract of the original article:

With each release of Microsoft SharePoint, developers ask for  additional web services to simplify reading and writing SharePoint site  data from custom code not on the server that is running SharePoint.  Instead of building more and more web services, Microsoft introduced in  SharePoint 2010 the client object model,  which contains a familiar  subset of frequently used objects. The client object model is very  similar to the SharePoint server object model. This SharePoint Visual  How To demonstrates how to use the SharePoint 2010 .NET client object model.

 Code It 
In your project, add references to the two required assemblies that compose the .NET client object model. These two assembles (Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll) are located in the ISAPI folder of %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\. Connect to SharePoint and get some data. The example in the video demonstrates getting a list of product categories from a SharePoint list. All communication centers around the ClientContext object. This object is responsible for connecting to the server and sending all queued commands for processing. 
After you use either the ClientContext.Load method or the ClientContext.LoadQuery method to queue instructions, a call to the ClientContext.ExecuteQuery method triggers the communication back to the server. The sample  application in this Visual How To is a Windows Presentation Foundation  (WPF) application. Unlike the Microsoft Silverlight client object model, the .NET client object model does not include an asynchronous version  of the ExecuteQuery method. Therefore, to create a  user-friendly application, use the ThreadPool.QueueUserWorkItem method to communicate with SharePoint on a background thread. When the  thread finishes, it uses the Dispatcher to send a  delegate back to the initiating thread to update the user interface  (UI). This technique keeps the UI from locking up while waiting for the ExecuteQuery method to complete.

Click here to visit the original article, its really good one for  developers who work with SharePoint 2010

No comments:

Post a Comment