Site Customization Versus Site Development in SharePoint 2010

Later this month, Microsoft will release the final RTM version of SharePoint 2010. This release of SharePoint 2010 includes two main products: SharePoint Foundation and SharePoint Server 2010. SharePoint Foundation is a free download which provides the core infrastructure and development platform for SharePoint 2010. SharePoint Server 2010 provides a set of components and services offering extra business value on top of SharePoint Foundation. It comes in several different versions, each with its own specific licensing costs. Whether you choose SharePoint Foundation or SharePoint 2010, it will be crucial that you differentiate between customization and development.

SharePoint Foundation is very flexible from the user perspective because it was designed to support high levels of site customization. You no longer need to be a developer to build a complex and highly functional web site. Today, there are many sophisticated users capable of customizing SharePoint sites for an increasingly large number of business scenarios.

If you are architecting or planning a large deployment with SharePoint 2010, it’s important for you to understand the limitations of site customization. SharePoint Foundation tracks site customizations by modifying database records within a special SQL database known as the content database. This is true when you customize a site through the browser by creating a new list or activating a feature. It’s also true for all types of site customization you can perform using SharePoint Designer 2010.

The fact that all site customization is recorded as modifications to the content database is both a strength and a weakness for SharePoint 2010. It's a strength because it provides so much flexibility to users and site administrators with respect to performing ad-hoc customizations. It's a weakness from the perspective of a professional software developer because site customizations are hard to version and can be hard or impossible to make repeatable across site collections and farms.

A professional .NET developer can work at a level underneath the SharePoint site customization infrastructure. To be more specific, a developer can create SharePoint solutions using Visual Studio 2010, which makes it possible to deploy reusable components and templates to the front-end web server. These low-level source files do not live inside the content database, but instead they are deployed directly to each front-end web server.

Working at this level is more complicated and has a steeper learning curve. However, it lets you centralize source code management and have a more disciplined approach involving code sign-off when moving functionality from development to staging to production.

This approach also makes versioning and reuse of custom business solutions and code far more manageable across multiple sites, web applications, and farms.

You should differentiate between site customization and SharePoint development according to these criteria. SharePoint site customizations involve updates to a site accomplished by making changes to the content database, generally through the web browser or SharePoint Designer 2010.

A site customization never requires touching any of the front-end web servers in the farm. Furthermore, site customizations can be made without any farm administration permissions. The user simply needs permissions within the site collection where the site was created.

SharePoint development, on the other hand, involves working with files that must be deployed to each front-end web server. As a SharePoint developer, you should understand that best practice deployment involves building all the files required for deployment into a special type of CAB file with a .wsp extension known as a solution package. The easiest way to develop a SharePoint solution that is built into a solution package is by working with the new SharePoint tools that ship as part of Visual Studio 2010.

Solution packages were introduced in SharePoint 2007. However, SharePoint 2007 allows you to deploy a solution package only at the farm level. SharePoint 2010 provides greater flexibility.

You can deploy a solution package in SharePoint 2010 as a farm solution, which is consistent with how deployment works in SharePoint 2007. You can alternatively deploy a solution package in SharePoint 2010 as a sandboxed solution, which reduces the scope of deployment from the level of the farm to that of a single site collection.

When you plan to develop a new SharePoint solution, you should consider whether you will ever want to deploy the resulting solution package as a sandboxed solution. If that is the case, you must learn how to create a SharePoint solution that can operate within the restrictions of the sandbox. I would recommend that you learn about sandboxed solutions in greater depth so you can answer questions about why, when, and how to use them.