Architecture

Sitefinity's multi-layer architecture is designed and built around the key concepts of extensibility, interoperability and integration, and flexibility. This is achieved by:

• Abstraction patterns that hide the implementation and storage location details
• Various extensibility points
• Public API for all the system components and services that build Sitefinity's out-of-the-box modules. 

The following diagram illustrates the application layers in a website running Sitefinity:

Sitefinity's N-tier application architecture allows stacked groups of system components isolated in layers, so you can make changes in one layer independently of the other layers.

The following sections describe each application layer in more details.

By default, Sitefinity CMS uses relational SQL DB storage for storing content and system data. The database layer for relational storage is implemented with the Telerik DataAccess ORM, which delivers support for Microsoft SQL. When storing media and documents, Sitefinity CMS enables you to use various file and blob storage providers, as well as external services. For example, database, file system, Azure blob storage, Amazon S3, MOVEit, and more. We recommend that the data persistence layer is a separate server deployment.

In Sitefinity CMS, provider patterns serve to abstract the storage location and the communication protocol for storing and retrieving content and system data that used by Sitefinity CMS modules. By default, Sitefinity CMS uses relational database storage providers, implemented with Telerik DataAccess ORM, for all modules. In addition, Sitefinity CMS also supports non-relational database storage. For example, users and roles can be retrieved from non-relational storage like LDAP (Active Directory) and, as a result, Sitefinity CMS has LDAP provider for users and roles. You can also use other storage providers for media files like images, videos, and documents and store them on external non-relational locations. Each module, for example News or Blogs, has a base abstract provider class that you need to implement to have a custom storage provider for the specific module at hand. Thus, you can store data in non-relational database storage or a database storage that is not supported by DataAccess.

Managers represent the business logic API. You use managers when working with the content and system data. Each module has its own manager class that provides the functionality for querying, storing, updating, deleting, and other more complex content-related tasks. Managers provide you with transactional unit of work API with which you can batch operations and commit it as a single unit. You can also combine separate manager operations in a single 2-phase commit transaction across modules and storage. When working with a manager, there usually is an underlying data provider, in which the manager delegates any CRUD operations. Managers hide the complexity of selecting the appropriate data provider, controlling the lifetime of transactions, supporting multisite environment, and so on. In addition, the layer of the developer productivity API facade, called the fluent API and located on top of the managers, simplifies even further common operations, resulting in less code lines and more readability.

Web services

REST HTTP web services enable external applications and clients to access and manage Sitefinity CMS content and system data over the HTTP protocol.

Sitefinity CMS web services give access to content retrieval, updating, and publishing. Sitefinity CMS also exposes its configuration and workflow as REST services. Most of the services in Sitefinity CMS are implemented in WCF. Some of the more recently developed REST services, for example inline editing and related data, are based on the service stack framework.

System services

You can use system services as .NET API for Sitefinity CMS modules extending the system. System services are core components that expose the following functionality:

• Email notifications
• Full text search
• Geo location
• Personalization (segmentation of users)
• Publishing to external systems
• Content workflow

You follow the implementation abstraction as pattern, so you can replace most of the system services with custom implementation.

HTTP handlers are the most commonly faced application layer, exposed by Sitefinity CMS. This layer serves all HTTP requests for rendering content, which are mostly generated by the browsers. HTTP handlers serve requests to render HTML pages, stream media, such as images, videos, documents, and others, for example the PageRouteHandler and the LibraryHttpHandler.

Before serving client requests the handlers check security-related issues and ensure content is properly protected. The page handler is one of the major components, as it serves browsers requests by first routing the request to the appropriate page by considering page URL, language, site, personalization segment, and so on. Next, the page handler makes sure the page is generated and compiled. Finally, the handler executes and potentially caches the output.

The most common clients are HTML browsers. Sitefinity CMS supports a variety of browsers, but there are some restrictions that apply for the backend. For more information, see System requirements.

Another developer productivity tool is Sitefinity CMS VSIX. It enables more convenient integration and deployment when developing with Microsoft Visual Studio and Sitefinity CMS.

Modules

A Sitefinity CMS module represents a functional sub-system of the CMS. Modules are highly decoupled entities and rely solely on the CMS infrastructure or on some of Sitefinity CMS core modules. That is, modules can be installed or uninstantiated separately and can package their own user interface, data storage, public API, public REST API, configuration, workflow, and so on. Most of Sitefinity CMS capabilities are wrapped as modules, for example News, Blogs, Libraries, Forms, Translations, Service hooks, and so on.

Modules usually leverage all the layers of the CMS architecture.

EventHub

Sitefinity CMS EventHub is an API where developers can subscribe for various system events that notify about activities completed in the system, for example updating of content, serving of page requests, unauthorized access, and so on. By hooking to these events, you can customize the system, for instance integrate with other systems, send custom notifications, or apply authorization and validation.