Joel's SharePoint Architecture Blog

SharePoint Server, SharePoint Online and Office 365 Training, Architecture, Administration and Development

You are here: Home / SharePoint / SharePoint Thing a Day – 043 – Development. CSOM Can Drive you Batch-It Crazy!

SharePoint Thing a Day – 043 – Development. CSOM Can Drive you Batch-It Crazy!

by

CSOM Can Drive you Batch-It Crazy!

#spthingaday 043 – Development. CSOM Can Drive you Batch-It Crazy! #SharePoint, #Office365, #Development.. If you're new to Client Side Object Model development, of course, it's not only a few class and object name changes you'll need to wrap your head around. The biggest difference between the Server Side and Client Side Object Models, is that CSOM is a batching API. It is designed to reduce the chattiness and statefulness that would occur if CSOM were simply based on the Server Side equivalent. Instead, CSOM requires that you enlist statements into a batch, and then fire the batch to the server when you're ready to have it execute. State in your client code is maintained by an object called ClientContext. In the constructor, you pass in the URL to the target Site Collection. ClientContext.Load is one of the methods you can use to tell CSOM: "Hey, I'm either going to need to read or write to this object. Add it to the batch." When you're ready to, you can call ClientConext.ExecuteQuery. There's also an async version called ExecuteQueryAsync. It's worth noting that although .NET managed code supports both of these methods, JavaScript only support asynchrony with CSOM. #microsoft #microsoftoffice #microsoftsharepoint #microsofttraining #officetraining #freetraining #trainingvideos #contentmanagement #enterprisecontentmanagement

A post shared by JFDI Consulting #spthingaday (@jfdiconsulting) on

If you’re new to Client Side Object Model development, of course, it’s not only a few class and object name changes you’ll need to wrap your head around.

The biggest difference between the Server Side and Client Side Object Models, is that CSOM is a batching API.

It is designed to reduce the chattiness and statefulness that would occur if CSOM were simply based on the Server Side equivalent.

Instead, CSOM requires that you enlist statements into a batch, and then fire the batch to the server when you’re ready to have it execute.

State in your client code is maintained by an object called ClientContext.

In the constructor, you pass in the URL to the target Site Collection.

ClientContext.Load is one of the methods you can use to tell CSOM: “Hey, I’m either going to need to read or write to this object. Add it to the batch.” When you’re ready to, you can call ClientConext.ExecuteQuery.

There’s also an async version called ExecuteQueryAsync.

It’s worth noting that although .NET managed code supports both of these methods, JavaScript only support asynchrony with CSOM.