Sitefinity's multi-layer architecture is designed and built around the key concepts of extensibility, interoperability and integration, and flexibility. This is achieved by:
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 payers.
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, Oracle, and My SQL databases. When storing media and documents, Sitefinity CMS enables you to use various file and blob storage providers, as well as services. For example, database, file system, Azure blob storage, Amazon S3, and so on. 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 storages. 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.
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.
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:
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 Thunder. Thunder enables more convenient integration and deployment when developing with Microsoft Visual Studio and Sitefinity CMS. Thunder utilizes HTTP REST services to communicate with Sitefinity.
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's functionality is wrapped as modules, for example News, Blogs, Libraries, Forms, E-commerce, and so on.
Modules usually leverage all the layers of the CMS architecture.
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.
Back To Top