Sitecore Fetch Squad

(Version 1.1 - October 11th, 2008)

In this series, I’m going to compare the functionality of SharePoint and Sitecore from a developer perspective in each area and both candidates can collect "points" from 0 (has nothing to contribute) to 10 (great integration and functionality).

This series will cover the following areas:
- Introduction (Part 1)
- Installation and General Architecture (Part 2)
- Configuration (Part 3)
- Customization and Designer Experience (Part 4)
- Integration with Developer Tools (Part 5)
- Feature Deployment (Part 6)
- API und Data Model (Part 7)
- Integration with other systems (Part
- Conclusion (Part 9)

Installation and General Architecture

Sitecore and SharePoint both come with a lot of out-of-the-box functionality but the main reason for choosing one of them as platform is extensibility of the core features. Both products are based on .NET, SQL Server and Windows Server / IIS. They both are basically also additional layer of functionality on top of ASP.NET 2.0, but this is already the first big difference in the overall architecture.

SharePoint is automatically installed by the SharePoint installation package (MSI) into the "Programs" folder of the system hard drive, some levels inside folders named "web server extensions" and so on. Because of the name of the last folder hierarchy level, developers usually refer to it as the "12 hive". All assemblies living somewhere in that directory tree are registered with the GAC (Global Assembly Cache), so every application in the system does not need to have a copy in their local /bin folder. When installing a first web application, SharePoint creates usually a new web inside IIS and places a few files in the related file folder on disc. It also registers several virtual directories linked to folders underneath the "12 hive". When the ASP.NET worker process (w3wp.exe using ASP.NET ISAPI) is starting up, it reads the contents of the Web.config in the configured IIS web folder. The Web.config refers to several assemblies available from the GAC which are loaded and initialized during startup (HTTP Modules, HTTP Handlers, some lifecycle components and so on). When a user requests a URL from SharePoint, a component named SPVirtualPathProvider is responsible for fulfilling the request as it has been registered as VirtualPathProvider. The component either ignores the request if it targets one of the virtual directories or "redirects" it to a HTTP handler that reads pages from the SharePoint content database.

Advantages

1. Multiple SharePoint sites are using the same assemblies and functionality. Simplifies updates and development of global features.
2. SharePoint pages are located in a central location on the file system or in the SharePoint content database. This enables an optimized handling of customized pages (SharePoint refers to pages that were changed by users and stored in the content database as "customized" pages) within a SharePoint farm where more than one web server is handling the request as the pages are instantly available to all webfarm servers by accessing the database. It also enables versioning and integration with other SharePoint features (workflows, etc.).

Drawbacks

1. Multiple SharePoint sites are using the same assemblies and functionality. Running different or more than one highly customized versions on the same server is nearly impossible.
2. Administrators cannot choose the location SharePoint is installed in. Complicates separation of responsibilities on the server with respect to security.
3. SharePoint pages are located in a central location on the file system or in the SharePoint content database. This may lead to some confusion if developing new features for SharePoint or customizing existing pages, because it is different from the usual way developers interact with the ASP.NET WebForms framework. It also complicates integration with VisualStudio, but we will cover that later in this series.
4. SharePoint heavily customizes the ASP.NET pipeline to integrate its database-centric concept. It also dynamically decides based on several parameters where to look for the requested resource (in the local IIS web folder, in the central SharePoint installation directory or in the content database), which is not trivial and at first not easy to understand.

Sitecore can be installed in two different ways. The first way is to install it using the Sitecore Installer, a MSI package that needs to be executed on the server, similar to a SharePoint installation. The installer asks you a few questions and is doing all the work for you, including installing the database and creating a new IIS web. There is, however, a second option: You also can install Sitecore "by hand". I will not go into detail here as the documentation at SDN (Sitecore Developer Network) provides you with all necessary information. Generally speaking, you can upload and install Sitecore even with a simple FTP account and remote access to your database.
That means, from an ASP.NET perspective, Sitecore is just like any other ASP.NET application with no special treatment or "special" IIS configuration. Any Sitecore installation creates some additional folders that are usually placed outside of the configured IIS web folder, but - if necessary - you can move them everywhere you want.
No matter which way you choose, you can have multiple installations of Sitecore on a single Windows installation. In contrast to SharePoint, you can even install Sitecore on Windows XP and Windows Vista, and you can not only run it using IIS, but also using VisualStudio’s WebDevelopment server - but we will cover that in more detail in a later part of the series.
Of course no one can keep you from moving all Sitecore assemblies from the /bin folder to another location and register them in the GAC, so you can share the assemblies across multiple Sitecore installations. I for myself have actually never done that (because updating Sitecore is pretty easy), but it should be no big deal.
Every request to the application is handled by Sitecore using a lot of customized components (especially HTTP Modules and HTTP Handlers) that are registered in the Web.config file. The current version of Sitecore (6.0) performs a lot of initialization and routing operations before it hands off the request to the ASP.NET PageHandler, which then in turn opens an ASPX page with several Sitecore controls from the file system. It is no problem at all to replace the PageHandler with another HTTP Handler and store all the ASPX pages in another location (for example a database), or to do something totally different, but as far as ASP.NET is concerned, a request to a Sitecore application is just an ordinary HTTP request with some rewriting and an extended lifecycle.

Advantages

1. Two possible installation routines, Sitecore Installer and Manual Installation.
2. Multiple Sitecore installations CAN use the same assemblies and functionality.
3. Administrators have full control over where to install Sitecore.
4. Installing Sitecore is even possible with simple FTP und SQL accounts (although in a corporate environment, that may not be the most productive way).
5. Sitecore Layouts (Sitecore refers to ASPX pages as "layouts") are stored in the file folder of the IIS web. This makes it easy for developers to extend and customize pages as well as develop additional features as this way of handling files is aligned with the way the ASP.NET WebForms framework works. It also enables a nearly perfect integration with VisualStudio (see a later part).
6. Sitecore uses advanced ASP.NET features to extend the request pipeline and other components, but it does not change the way the framework is basically working that dramatically. This enables easy integration with other frameworks (e.g. Spring.NET) and libraries.

Drawbacks

1. Sitecore layouts (Sitecore refers to ASPX pages as "layouts") are stored in the file folder of the IIS web. In theory, this may lead to some problems with multiple Sitecore servers (content staging) and when it is necessary to extend layouts with versioning and workflows. In practice, there are several simple mechanisms available to handle those situations very effectively.

Okay, let’s wrap up part two. Both frameworks are essentially ASP.NET 2.0-based, but SharePoint ‘07 changes the way the ASP.NET WebForms framework usually handles things pretty dramatically, although it is much better integrated with IIS and ASP.NET than its predecessor (SharePoint 2.0). Sitecore is more or less a simple ASP.NET web application with advanced functionality, deeply integrated with the .NET Web Platform. Especially from a developer perspective, Sitecore definitely deserves some extra credit for transparency and architecture.

Sitecore: +9 points = 9 points total
SharePoint: +5 points = 5 points total

The next part of this series covers the topic Configuration.