Sandbox vs. Client Object Model

By Peter Serzo

July 17, 2012 —  (Page 2 of 2)
The second occasion where I came to crossroads regarding these two technologies had to do with site configuration changes. After a site was created, the customer wanted several changes to it implemented. A sandbox solution made sense in this context for the following reasons:

Sites were not being created every day, so there was not much concern regarding the resource quota. They wanted the changes to happen after the site was created. I used an event feature receiver that was activated manually after the site was created. Furthermore, utilizing a list, I was able to create parameters that are edited by power users without having to recompile the code.

In both cases, I could have used either technology. But just like the baseball players I wrote about earlier, it is about using the technology that will have the best chance to be successful in that position.

The Client Object Model takes a good portion of the load off of the server and performs well. You can integrate it with jQuery and HTML to create an effective solution. A sandbox solution is terrific when you want to create a solution that will be executed occasionally without integration with other client-side technologies.

The end result will be a win where all parties are successful. For now, I am going to REST.

(Come see me speak about four more real-world solutions I have encountered for the Client Object Model next week in Boston at SPTechCon!)

Peter Serzo is a published author of the “SharePoint 2010 Administration Cookbook,” a founder of the SouthEastern SharePoint group, a speaker, and SharePoint Architect for High Monkey Consulting. Peter has been in the IT industry for 20 years. He has extensive experience with SharePoint implementing business solutions for several enterprise organizations over the past seven years.



Share this link: http://www.sptechweb.com/link/36803