As you saw in the preceding code snippets, although the Client Object Model defines clientside representations of server objects and we can create instances of those objects in our code, the objects are not populated with a copy of the server-side data until it is explicitly loaded.
This Silverlight code snippet shows how to execute a Collaborative Application Markup Language (CAML) query against a list:
The important thing to note about these code samples is the use of the ClientContext.Load method. This method flags the passed in object to be populated the next time ExecuteQueryAsync is called, so in the preceding example, ctx.Load(listItems) will flag the listItems object for population.
To use these code snippets with the demo project that we set up earlier, take the following steps—first, for the Silverlight sample:
Although property values are not populated until they are explicitly loaded, it is still possible to make use of the properties in expressions, as long as the expressions themselves are not enumerated until after the properties are loaded. In our code sample, we can see an example of this in the following line:List announcements = ctx.Web.Lists.GetByTitle("Announcements");
If we were to attempt to enumerate any of the properties of the announcements object, an error would be thrown since the value has not been initialized. The same is also true of the properties of the object referred to by the ctx.Web property. We can use the property in an expression because an expression uses a reference to the property rather than its actual value.
You can see that our code sample makes use of the announcements object in various places, but we never explicitly populate it. Loading an object is necessary only if its properties will be converted to a value. One easy way to look at it is to consider that each object is a proxy for an appropriate server-side object. Using the proxy, we can perform many of the same actions, but until we explicitly load data from the real object into the proxy, we can’t use the data on the client side because it exists only on the server.
Filtering Returned Data
When we execute the preceding code samples, a table is generated containing the field values that are returned for each list item, as shown:
This works well and doesn’t present much of a problem when only a few items are included in the list or library. But what happens if tens of thousands of items are included and we need only one or two columns? Transferring all this redundant data to the client would have a major performance impact. Thankfully, we can eliminate redundant data by filtering the properties that are populated by the Load method, as the following snippets show. To see the results of these samples, create a new button and hook up the Click event to the sample code, as we’ve done in the past few samples.
Here’s the snippet in Silverlight:
You can see that by running these samples, the resulting table contains only the Title column. Although you can’t see it from the output, the population of the fields collection has been filtered to include only the properties that are required for the logic. The result of these changes is that the data exchanged between client and server is greatly reduced.
NOTE When querying lists or libraries, you need to be aware of how filtering is applied behind the scenes. First, the CAML query object passed into the GetItems method is used to retrieve a list of items into memory. With the item list in memory, LINQ to Objects is used to apply the filters that we’re defining with the Load method. This is significant, because when you’re querying large lists,item-level filtering should always be done using CAML to reduce the memory usage on the server restrictions are imposed on the number of items that can be retrieved from a list in a single query.
In addition to the ClientContext.Load method used in the preceding examples, the Client Object Model also provides a ClientContext.LoadQuery method. The difference between these two methods is in the object that receives the results of the method. When calling Load, we’ll pass in a reference to the object that we want to load along with any filtering expression; when the method has executed, that object that we passed in is loaded with the appropriate data. With LoadQuery, when the method has executed, an IEnumerable(T) collection is returned.
You may be wondering about the benefits of such a subtle difference between these methods. The main benefit is that LoadQuery can accept a LINQ query as a parameter; also, the results returned can be further processed using LINQ. In the preceding Silverlight example, we could replace this
Share Point 2010 Related Interview Questions
|Web Services Interview Questions||XML Interview Questions|
|Share Point 2010 Interview Questions||ASP.NET Interview Questions|
|Share Point Administration Interview Questions||BizTalk Admin Interview Questions|
|Microsoft Office SharePoint Server (MOSS) Interview Questions||Biztalk Server Interview Questions|
|Asp Dot Net Mvc 4 Interview Questions||Biztalk Esb Toolkit Interview Questions|
|InfoPath Interview Questions|
Share Point 2010 Tutorial
The Microsoft Sharepoint 2010 Platform
Developing With Sharepoint 2010
Presentation Layer Overview
Client Object Model
Infopath Forms Services
Enterprise Content Management
User Interface Customization
Application Services Overview
Service Application Framework
Word Automation Services
Data Access Overview
Linq To Sharepoint And Spmetal
Business Connectivity Services
User Profiles And Social Data
Packaging And Deployment Model
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.