This past weekend, I was coaching my son’s baseball team, and after several frustrating losses, we got a win in our last game. Why? We decided that instead of trying to make the parents and players happy by playing positions they wanted but were not as skilled at, we put them in positions where they would be successful. The outcome is that all parties (parents, players and coaches) were happy.

SharePoint is like that tournament team. There are many ways to successfully accomplish a task in SharePoint. While Microsoft touts this as a feature, this is a source of frustration to users, including developers. The issue I am addressing in this article is to give you guidance in regard to when to implement a sandbox solution versus a Client Object Model solution.

Since there has been plenty written regarding these technologies from a how-to standpoint, I am going to address two real-world scenarios.

Last week, I was speaking to a customer about a dynamic site map they wanted to implement. They asked for my comments regarding a sandbox solution they found online. This solution creates a dynamic site map when the page renders. I steered him away from this and toward the Client Object Model.

While the sandbox solution would work, the problem lies in the resource quota that is consumed every time the page is rendered. The customer had a public site that has the potential to be hit thousands of times a day. If that page is rendered even half the time, it is conceivable that resource quotas will be met quickly. These will have to be raised in accordance with the popularity of the site. This was not a good fit for a sandbox solution.

I steered him to the Client Object Model (which I believe is a Top 3 technology improvement that was introduced with SharePoint 2010). Over the last two years, I have personally utilized it on public websites that get hit thousands of times a day. Some of these websites get extensive traffic from as far away as India. The sites are still responsive. The best part is that much of the code that has been written for the sandbox solution can be reused! Now when the page is rendered, this code is run client-side and sent to the server for response.

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.