SharePoint 2007 Site Templates vs. Site Definitions

There is an ongoing debate between SharePoint developers regarding the best approach for packaging and deploying customized SharePoint solutions.
One easy approach is to use site templates, but my opinion is that for a developer who are concerned about system performance and who needs finer control over cusomization, a site definition is the better option.

I found that building some sort of custom site provisioning provider works the best.

Below is my analysis of the differences between site definitions vs. site templates and at the bottom is a summary of the approach I prefer for deploying custom SharePoint solutions.

What is a Site Definition?
A Site definition is the core definition of what a site is in SharePoint.
User content on a SharePoint site is located in a SQL Server database.
All the code and the pages that are used to administer and render the SharePoint site are stored as physical files on the web server.
A site definition exists as physical files on the web server and defines, through the use of SharePoint’s XML schema (known as CAML), the lists, columns, features etc. that should be created / activated when a site is created. (The files includes .aspx pages and .xml files)
A site definition is installed on file system of web front ends, located at ..\12\Template\SiteTemplates. This directory is language-neutral.
Site definition files are cached in memory on the server at process start-up of Microsoft Internet Information Services (IIS), which improves scalability and performance by reducing unnecessary data storage or retrieval, and by allowing uncustomized pages to be reused across sites. The information contained in these files is pulled from the cache at run time. Pages and list schemas are read from the site definition files but appear to be actual files within a site.
 
What is a Site Template?
A site template (*.stp file) is created through the user interface or through implementation of the object model. It is a package containing a set of differences and changes from a base site definition.
The site template package is stored as a CAB-based file that can be downloaded or uploaded to site collections by users with the appropriate rights.
It is not as performant as a pure site definition as site definitions are cached on start of IIS on the web front ends while site templates are stored and hence need to be fetched from the content database and merged with the site definition code at runtime to render the site.


Deciding Between Site Definitions and Custom Site Templates
 
Site Templates

• Easy to create.
• You do not need to be a server administrator on the Web server to create and deploy site templates.
• Easiest way for system administrators to extend SharePoint without requirement for development skills.
• Deployment is simple because template data is stored centrally in the configuration database.
• Because it is slow to store templates in and retrieve them from the database, site templates can result in slower performance.
• The contents of unghosted pages are routed through the Safe Mode parser, which prevents server-side code from executing, and which depends entirely on the Safe Controls list specified in the web.config file of the wwwroot directory to determine which controls can be rendered at run time.
• You can modify a site template without affecting existing sites created by the template.
• Custom templates can be modified without affecting existing sites that have been created from the templates.
• Custom templates are not created in a development environment.
• If the site definition on which the custom template is based does not exist on the front-end server or servers, the custom template will not work.
• If you plan to transfer a site template to separate farm, that the farms have the same versions installed of SharePoint installed. (hotfixes,etc.) This is due to the dependence site templates have on the original base site definition they were created from.

Site Definitions:

• Complex and laborious to create.
• Administrators must always be involved in the deployment of site definitions.
• Most appropriate for third-party developers.
• Deploying a site definition requires more work.
• Site definition files are cached in memory on the server at process start-up of Microsoft Internet Information Services (IIS), which improves scalability and performance by reducing unnecessary data storage or retrieval.
• Uncustomized pages to be reused across sites.
• You can achieve a finer level of customization by directly editing all the schema files.
• Custom site definitions are version and upgrade independent.
• Subsequent upgrades to SharePoint Products and Technologies may overwrite existing default site definitions. Using custom site definitions excludes your sites from potential upgrade issues.
• There is no easy way to modify site definitions once they are deployed
• Doing anything other than adding code can break existing sites
• Users cannot apply a SharePoint theme through a site definition.
• Customizing site definitions requires access to the file system of the front-end Web server.
• Multiple root-level pages -- In a site definition, you can define several root-level pages. Instead of your sites having one page, they can have many.
• Template picker pages -- You have the ability to change the icon that displays in conjunction with the template so it stands out as you create the templates.
• Microsoft doesn't support changes made to a site definition after you've created the sites.
• Multiple lists of the same type -- Because of the structure of CAML and the ONET.XML file, you can't create multiple lists from the same list definition and put them on the same page.

Summary of my preferred approach:
I found that building a custom site provisioning provider works the best.
This means that I build my SharePoint artefacts - lists, libraries, web parts, custom forms, etc. using SharePoint, SharePoint Designer and Visual Studio. When I am then ready to package and deploy my custom SharePoint solution I use the SharePoint Solutions Generator - part of Microsoft SharePoint Developer Tools 9.0 to create list and library definition features.
Once I have my list and library definitions in place I create a Visual Studio WSP Builder project with an Feature Event Receiver.
In the "activate" event I add logic to activate the definition features and in the "deactivating" event I do a cleanup (deactivate definition features and remove web parts)


This means the following will happen when one of my solutions are deployed / retracted:
1. The user creates a blank SharePoint site. (previously team site)
2. The user runs a Setup.exe file.
3. This file is the un-customized Codeplex Solutions Installer and will read configuration data from Setup.exe.config
4. The file will open a deployment wizard which guides the user through a series of screens to ensure successful solution deployment.
5. After successful deployment the user follow instructions from the deployment guide to execute a single stsadm.exe command.
6. This command will activate a single hidden feature.
7. The single feature which gets activated will do the following on the site:

• Set the new site title.
• Check environment for previously installed features which are still active
• Activate Web Features in the correct order 
• Activate Site Collection Features
• Allows activation of generic site collection features – shared among more than 1 solution.
• Clear Site Structure – remove unwanted artefacts
• Set Site Structure – build Quick Launch Items, Set Web Parts on Default.aspx page etc.

8. During deactivation of the single “configuration” feature the following will happen:

• Set the new site title back to default.
• Deactivate Web Features in the correct order 
• Deactivate Site Collection Features
• Clear Site Structure – remove unwanted artefacts
• I do not delete lists or libraries which contain data – do not want to delete data.

Benefits of this approach:

• Allows dependencies between hidden features - lookup lists
• Allows list to be automatically instantiated with default data
• Allows library content – like UDCX files to be configured with new environmental values (link InfoPath Form to dynamic data connections)
• Allows activation of web part features to site collection scope
• Allows validation and upload of InfoPath Forms (using site collection feature)
• Allows publishing of InfoPath Form to site collection forms library
• Leverage off the benefits of using definitions. 

I hope this will help you to choose the best approach for the kind of SharePoint solutions which you need to deploy... good luck !!


Further reading and references:
http://itfootprint.wordpress.com/2007/04/18/sharepoint-site-template-vs-site-definition/
http://msdn.microsoft.com/en-us/library/ms980852.aspx
http://mymemorysucks.wordpress.com/2009/02/25/site-definitions-vs-site-templates-and-site-provisioning-providers/
http://my.advisor.com/doc/17614
http://blogs.msdn.com/b/brianwilson/archive/2008/07/13/site-definitions-versus-site-templates-and-deciding-on-the-correct-customization-approach.aspx