Client Application Models in SharePoint 2010

One of the most significant additions to Microsoft® SharePoint® 2010 is new and enhanced client-side functionality. The increasing prevalence of rich Internet application (RIA) technologies that run in the browser to deliver an enriched user experience, such as Ajax and Microsoft Silverlight®, means that traditional server-side development techniques are no longer sufficient for meeting the expectations of today's users. Users increasingly expect seamless access to data regardless of platform, whether from a browser window, a Microsoft Office® client application, or a custom solution. To meet these evolving needs, SharePoint 2010 introduces native support for RIA technologies and several new mechanisms for client-side, or remote, data access.

So what do we mean when we speak of a client application? In the context of SharePoint development, we mean any logic that interacts with SharePoint data from an external computer. This includes logic that executes in the browser, such as JavaScript or Silverlight applications, as well as Office applications and stand-alone solutions. This also includes applications that run on mobile devices, but that is beyond the scope of this document.

Typically, there are three main reasons for developing client-side logic that interacts with a SharePoint environment:

  • You want to provide a richer user experience on a SharePoint web page.
  • You want to perform actions that are unavailable to server-side code running in the sandbox environment, such as accessing information from multiple site collections or retrieving data from an external service.
  • You want to access and manipulate SharePoint data from another application, such as an Office client application or a custom solution.

When you design a client application for SharePoint 2010, the factors driving your decisions fall into two broad areas:

  • User experience. This describes the platform that your users will use to interact with SharePoint and the technologies on which you will build your application.
  • Data access. This is the mechanism by which your application will communicate with the SharePoint server in order to retrieve and manipulate data.

The following illustration shows some of the options available to you in each of these areas.

Client application considerations for SharePoint 2010


In many cases, a particular approach to user experience will lend itself to a particular data access mechanism. For example, the ECMAScript client object model will clearly lend itself to Ajax clients, the Silverlight client object model is designed for Silverlight clients, and the REST interface will be the best approach for accessing SharePoint data from clients that are not based on Microsoft Windows®. However, there are scenarios in which the choice is not so clear cut. This documentation identifies some of the nuances, advantages, and drawbacks to the different approaches to building a user experience and accessing data from client-side logic. The Client reference implementation that accompanies this section also provides a side-by-side comparison of each approach to client-side data access.

This documentation includes the following sections and topics that will help you to understand the key issues around client application development for SharePoint 2010:

  • Overview of User Experience Approaches. This topic describes the different approaches you can take to building a rich user experience for SharePoint clients. It explains the core functionality behind each approach and describes how client-server communication works in each case.
  • RIA Technologies: Benefits, Tradeoffs, and Considerations. This topic focuses on the use of Ajax and Silverlight to build SharePoint clients. It examines the advantages and disadvantages of each approach, and compares it to a traditional thin-client page model. The topic focuses on performance considerations, including initial load time, caching strategies, and responsiveness.
  • Data Access for Client Applications. This section provides detailed insights into the use of the client-side object model and the REST interface, and examines how you can optimize the performance of client applications when you use these data access mechanisms.

What's Not Covered in This Documentation?

Building user experiences for SharePoint could constitute a whole book in itself. This guidance focuses primarily on rich Internet applications (RIAs) and the underlying data access mechanisms that support these approaches. The following topics are out of scope:

  • The Business Connectivity Services (BCS) client runtime and Office client integration are not included. These features certainly introduce many new capabilities to SharePoint and Office, and really change the way you should view Office clients, allowing them to serve as a vehicle for extending line of business (LOB) applications. However the scope of the technology is quite broad, and consequently we were unable to fit it into this release. For a conceptual overview of the BCS client runtime, see Understanding Business Connectivity Services and Microsoft Business Connectivity Services Model. For examples of how to work with the BCS client runtime, see Business Connectivity Services: How-tos and Walkthroughs and Business Connectivity Services: Sample XML and Code Examples.
  • The majority of server-side approaches to user experience, including branding, master pages, delegate controls, publishing page layouts, and related concepts, are not included. These are all very important topics to SharePoint, but they are enhanced, not new, in this release. The scope of this topic is also very broad. We highlight some of the new server-side concepts for user experience such as Visual Web Parts, the ribbon, and dialogs, but only when the context requires it; thus, the coverage is not complete.
  • No tutorial or in-depth coverage of Ajax, JavaScript, or Silverlight programming is included. We describe how these approaches apply to client-side SharePoint development, but the programming techniques for each technology are well documented elsewhere.