I am writing a Silverlight control which will display the data from SharePoint list for use in SharePoint 2010 site.

I am considering wheather to use Client Object Model or SharePoint web services to achieve this task ?

Are there any criteria or performance considerations in deciding which to use when ?


There has been a post on this topic by author of SPServces. Including the link below


5 Answers 5


If you can you should use the Client Object Model (CSOM) - it does not support that many features as the web services but are superior in a number of ways such as:

  • data types
  • batching of commands (more efficient usage of bandwith)
  • optimization of data loaded (more efficient usage of bandwidth)
  • more similar to the server side object model in terms of programming (the web services are in most cases just huge chunks of undocumented XML you need to parse)
  • ...

So, for performance you will likely suceed better using CSOM


You actually calling a web service when you use client object model according to this link. Of course use web service is more direct but i dont really care about performance penalty by using Client Object Model. The more concern is productivity improvement by using client object model. But if you more comfortable using web service, you can use it.


Client Object Model was designed to work mainly with list data, so the API is somehow limitted. Working with web services does not always mean parsing XML data, you can use REST API (ListData.svc) that will return JSON output. Some webservices allow to switch between SOAP and JSON response format. So, my advice would be use Client Object Model when suitable (lists, security), and in other scenarios call SharePoint web services.


I think using the Client-Object Model is the suitable option because as it's meant to be used with tools like Silverlight, .NET, etc.

Also it provides more benefits.

  • 1
    Actually using web services gives you more option and access to more features, but CSOM is the preferred way if you're limiting yourself to lists and SharePoint Foundation stuff Jan 2, 2012 at 15:42

This MSDN article should also be listed when answering this question:
Deciding Which SharePoint 2010 API to Use

Server-side Object Model

The server-side object model provides the most extensive set of options for extending the capabilities of SharePoint 2010. It consists of every API that is documented in a class library in the SharePoint 2010 Class Libraries and Web Service References section of the Microsoft SharePoint 2010 Software Development Kit (SDK). Any application that uses these APIs must be physically deployed on the server. See Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7, and Windows Server 2008 for guidance on and options for setting up a development environment. In terms of security, these APIs usually have a high level of access, but see Sandboxed Solutions for limitations that are related to sandboxed solutions. This set of APIs provides access to the largest number of features and capabilities. In Microsoft SharePoint Foundation 2010, many of the server-side APIs reside in the Microsoft.SharePoint assembly (Microsoft.SharePoint.dll); in Microsoft SharePoint Server 2010, many of these APIs reside in the Microsoft.Office.Server assembly (Microsoft.Office.Server.dll). However, you must look at the documentation for each type and member in each API to determine which assembly to reference.

Client Object Model

The client object model allows you to integrate SharePoint 2010 capabilities into script that executes in the browser, code (no earlier than Microsoft .NET Framework 3.5) that executes in a .NET Framework managed application, or code that executes in a Microsoft Silverlight application. The APIs in the client object model are wrappers around a custom Web service that dispatches the calls to the server-side object model. They generally provide better performance than the SharePoint 2010 Web services because they batch requests and perform all operations asynchronously. They also feature design traits (such as object model hierarchy, object identity, data retrieval semantics, client context, infrastructural client objects, collections, and exception handling) that are familiar to SharePoint 2010 developers, and to Microsoft ASP.NET developers more generally. SharePoint 2010 provides an unmanaged ECMAScript (JavaScript, JScript) object model for script that executes in the browser. The unmanaged client object model is a good option for Web developers who are not familiar with ASP.NET development. The client object model focuses on the most relevant APIs for client-side development, and does not contain all the types and members that are represented in the server-side object model. The client object model is designed for use in remote client-side solutions that run on computers where SharePoint 2010 is not installed. See SharePoint 2010 Client Object Model for more information about the client object model and how to use it. The types and members in these APIs are documented in Client Class Library (for code that executes in a .NET managed application or in a Microsoft Silverlight 2.0 application) and JavaScript Class Library (for code that executes in the browser).

SharePoint 2010 Web Services

The SharePoint 2010 Web services allow you to integrate SharePoint capabilities into code that runs remotely in client-side or server-side applications that run on computers where SharePoint 2010 has not been installed. SharePoint 2010 provides a limited set of REST interfaces for developers who are familiar with that standard. The Web services provide a fuller range of capabilities than the managed client object model, but they do not provide the same performance and design advantages, such as batching and exception handling. When you develop client-side applications, you should use the managed client object model whenever possible. The SharePoint 2010 Web services APIs are documented in SharePoint 2010 Web Services and in SharePoint Foundation REST Interface.

  • Please add more details to this answer, Link only answers are doomed to be unhelpful in time (when the link breaks) :) Mar 6, 2014 at 10:44
  • @RobertLindgren yeah its from my early days :) Mar 6, 2014 at 10:46
  • I though so, but nice of you to update it! Mar 6, 2014 at 10:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.