This topic provides an overview of the architecture of Sitefinity.

Sitefinity is a Content Management System (CMS) application, which means that its primary goal is to create and manage content displayed on a Web site. To be efficient while working with Sitefinity it is advisable to get to know the underlying architecture before actual development has been started.

Sitefinity consists of five major parts and common infrastructure illustrated on Figure 1:

Figure 1 – Sitefinity Architecture

The major parts of Sitefinity are:

1. Pages
2. Controls
3. Modules
4. Services
5. Tools

The common infrastructure shared between various parts of Sitefinity at the moment includes:

1. Security
2. Workflow
3. File Manager
4. Personalization Framework

Pages

Every Web site consists of pages and Sitefinity Web sites are no exception. Pages in Sitefinity, however, have some peculiarities. As shown in Figure 1, the appearance of a page is defined by templates and themes, while its functionality is defined through controls. In Sitefinity, there is no actual underlying file for a page - it is constructed on the fly.

To fully understand the concept, see the following comparison between a classic HTML page and a Sitefinity page:

Table 1

Every page has a number of properties, such as Title, URL and so on. In addition to that, page serves as a container for controls, which will display actual content. The layout of the page is defined by its template, while its look and feel are defined through its theme.

Controls

Controls represent actual content or functionality. Controls cannot live outside of a page, which means that in order to use a control you need to have a page on which this control will be placed. Controls can be very simple. Such is Generic Content which simply displays unstructured content like text and images. But controls could also be very complex. Such is Forum which provides a complete front end for the forums application.

Built-in Controls

There are several types of controls you can use. First are the built-in controls, such as SiteMenu, Image or SiteTabStrip. These controls are added to the page toolbox by default and you can use them out of the box.

Module Controls

Other types of controls are module controls. Generally, every module needs to be represented on the public side. For example, the News module has a NewsView control which displays news created through the News module. Module controls are also added to the toolbox automatically.

RadControls

Sitefinity also comes with the complete suite of Telerik award-winning RadControls. Usable controls such as TreeView, Menu, RadEditor and so on, can be used directly through Sitefinity. While not all RadControls are added to the toolbox by default, they can be easily added through web.config.

User and Custom Controls

If none of these controls satisfy the needs of your development, you have an option to extend the toolbox with your own controls. You can add User Controls (.ascx) or Custom Controls (.dll) to your toolbox. There are no special requirements that your controls need to follow in order to function inside of Sitefinity. This means that you can easily add 3rd party controls or use some of your controls that have not been built specifically for Sitefinity.

Modules

Modules are small, independent applications living inside of Sitefinity. Sitefinity comes with several pre-built modules such as “News”, “Blogs”, “Images & Documents”. In addition to that Sitefinity can be easily extended through new modules. When creating a new module, the developer has a choice between creating an intra-site module and pluggable module. Modules in general, have administrative interface and public side controls. The administrative interface is used for any kind of work that should be done by authorized users (such as creating content), while public controls can be placed on pages like any other control (such as for displaying content).

Services

While both Pages and Controls are very tangible and visible parts of Sitefinity, often some common functionality is not directly visible to the end user and it is defined as a service. A good example of a service is “Search”. Search is a functionality that usually takes place on the backstage, indexing the content. Some simple Controls will display a box for entering a query or display a list of the results, but it is actually the service that will be doing the heavy lifting. A question may arise as why not implement search as a Module, but rather as a service. The answer to this question lays in the fact that Modules should generally be independent applications, while services – as the name suggest – have the purpose of serving some kind of functionality to other parts of Sitefinity. So, a solid implementation of Search service should make it easy for all other parts of Sitefinity to implement searching functionality. A good service should have no problems serving the functionality to pages, controls or modules. An example of this way of thinking is Search service, which abstracts away most of the complex tasks related to search and provides an easy way for modules and pages to implement search functionality.

Tools

All the major parts of Sitefinity discussed so far had one thing in common: they were all providing functionality for the site visitors, be it in a visible way, such as pages and controls, or more subtle way like services. Tools on the other hand are small applications inside of Sitefinity that generally have no impact on the visitors of the site. Their role is to provide functionality for the site administrators or Sitefinity itself. A good example of a Tool would be a reporting tool. Tools have no public side user interface and they are located exclusively in the admin side of Sitefinity.

Extending Sitefinity Major Parts

All major parts of Sitefinity, with the exception of Pages, can be easily extended. New controls can be created and added to the toolbox; new modules can be developed and loaded in Sitefinity, as well as new services and tools.

The Interplay

The interaction between the major parts of Sitefinity is illustrated in Figure 1 by the arrows. Pages, which contain Controls, are the central place of the whole application. Modules provide public controls and in this way directly affect Pages and Controls. Services can be used either by Pages, Modules or Services (such as search service) while Tools can use any of the major parts to perform the required functionality (for example, a reporting tool can query all the modules for specific data).

Common Infrastructure

Apart from the major parts of Sitefinity, there is a common infrastructure which is used by all major parts such as security, workflow, file manager or personalization.

Security

Security in Sitefinity is based on top of the ASP.NET Membership system. This means that all the features (such as users, roles, profiles and so on) commonly accessible in any ASP.NET application are present in Sitefinity as well. All modules, pages, controls and other parts of Sitefinity have access to the same security API and can take advantage of it at any given time.

Workflow

Currently Sitefinity supports custom workflow system, which is actively used by Pages and Generic Content based modules. In the near future Sitefinity will integrate Windows Workflow Foundation solution and thus allow full and flexible implementation of workflow functionality across the whole application.

File Manager

The file manager is a crossover between a major part and a tool, providing an API and user interface for working with the file system of any Sitefinity Web site.

Personalization Framework

Personalization framework is a relatively new feature of Sitefinity which provides API for storing various information on user-by-user basis. The current implementation is mostly visible at the dashboard of Sitefinity, while fully exposed API allows any developer to take advantage of personalization framework when developing modules or controls.

See Also

© 2002-2008 Telerik. All Rights Reserved.