Provider model

The built-in ASP.NET features such as membership, profiles, and sitemap, are taking advantage of the provider model. By implementing it, Microsoft allows developers to use membership system with various databases and various settings, while using only minimal coding and modifications.

Following are few examples of Sitefinity CMS features that are based on the provider model:

• Modules
• Security
• Taxonomies

For more information about the complete set of features, see Sitefinity Features & Capabilities.

The definition of the provider model implies that, if something is built on this model, it allows multiple implementations. This means that you can implement a provider for the Blogs module that will, for example, store all the blog posts in text files, instead of SQL Server. Another possibility is storing news on two different SQL Server databases. Basically, this means we could store data on different storages. For example, you want to send an email to the administrator of a website every time a new blog is saved. Creating a whole new Blog module just because of that small feature is too much work. The solution is actually very simple - to implement a new provider for the blogs module, inherit the standard Sitefinity CMS Blogs provider and simply override the “Save” method (call the base “Save” method to fulfill its built-in functionality, and after that write a few lines of code to send the email).

The various Manager classes in Sitefinity CMS hold and manage the information for a particular content type, such as News or Blogs. The providers govern the persistence of a particular content item, while the managers are managing all content type items. 

A site can be configured to access only a subset of providers. You configure which content and membership providers your site will use when you the sites of your multisite instance. This is abstracted away for accessing the content items through the relevant Manager class. Your Sitefinity CMS instance has one manager per content type, but can have many providers that are shared among the sites in a multisite setup.

NOTE: In Sitefinity CMS user interface, the providers are called Data sources and the managers are exposed as Libraries or Modules.

The data flow is the following - the site requests a content item through the relevant manager, the manager consults its providers, get the item from the provider containing it, and returns it to the site.

EXAMPLE: John is a guy who likes to send postcards. He has absolutely no idea what happens to postcards after he throws them in the mailbox and prefers it to stay that way. Sometimes, he sends postcards to his girlfriend in New York and he sends it with overnight delivery; sometimes, however, he sends it to his parents in Seattle but then sends it the standard way with 7 days delivery. The important thing that we need to take from this analogy is that John doesn’t know what happens to the postcard when he throws it in the mailbox (it gets picked up by a mailman). Mailman doesn’t know where John’s girlfriend lives, but he notices New York zip code so he sends it to the New York post office, which finally knows where John’s girlfriend lives and delivers the postcard. The similar principle applies to the Provider model implementation in Sitefinity CMS. When the “Save” button gets clicked on the user interface (John decides to send a postcard to his parents) and all it knows is that it should pass the data (postcard) and invoke a method on manager (throw the postcard in the mailbox). Manager (mailbox / mailman) gets instantiated with a proper provider (reads the zip code and decides to which post office to forward the postcard) and passes the data to the provider. Since both providers are of the same base class, they understand the data and action that is required of them (both New York and Seattle post offices are of base class “Post office” so they know what to do with a postcard which has an address on it). Finally, provider stores the data or performs some other action like deleting, updating or reading the data (to finish the analogy, Seattle post office delivers the postcard to John’s parents).

If a New York post office decides to introduce automated mail sorting to gain on productivity and replace the current manual sorting operation, how would that affect John? How would it affect John’s mailman or the mailbox across John’s street? Would it affect John’s parents or John’s girlfriend? The answer is no, it would not affect anyone except the New York post office which would become more productive. Same goes for Sitefinity: if you decide to add functionality on a certain provider method, this would not affect the user interface, it would not affect the manager class and it would not affect data storage.

Another important thing to note is that Sitefinity CMS supports multiple providers. This means that if you have defined two providers for news module, you will be able to choose with which provider you want to work when you are in the news module. Let’s assume you have three Sitefinity CMS Web sites and four SQL databases. Each Sitefinity CMS Web site has its own database, while the fourth database is used jointly by the three Web sites. The reason why you would implement this is because you want each Web site to have its own news, but you also want the three Web sites to share some news. So, every time the editors in any of the sites wants to create a new news item, they have a choice to create it only for that site (by using provider which stores data on the designated database) or to create it for all sites (by using provider which stores data on the fourth database, commonly used by all three Web sites). The diagram in Figure 2 demonstrates a scenario in which multiple providers could be used to recycle data between multiple Web sites.

Sitefinity CMS offers two types of providers - static and virtual.

You define the static providers in the configuration of your Sitefinity CMS deployment. Static providers are stored in the configurations on your file system and are created, modified, and deployed via the continuous delivery process.

A manager initializes all static providers for its content types during Sitefinity CMS startup. When you have many sites, this may slow down the startup of your Sitefinity CMS instance.

To access the static providers available to all sites, use the following code:

Virtual providers are stored in the database and are created runtime. The site administrators create a new virtual provider by adding new sources to their sites using the Sitefinity CMS backend. When a manger needs to initialize an instance of a virtual provider, it uses the information stored in the database, combines it with the information for the statically configured providers and finally creates the virtual provider.

A manager does not initialize its virtual providers, unless they are needed. This way, your Sitefinity CMS instance starts faster, and the machine resources are optimized.

To access all providers (static and virtual) accessible to a given site, use the following code:

In Sitefinity CMS, a provider is essentially a set of configuration data describing how Sitefinity CMS can persist a specific content type. For static providers, this may be a connection string to a database. Virtual providers, however, combine the data from a static provider and adds the application name. The application name is the identifier recorded in the database. Using this abstraction, Sitefinity CMS can separate the virtual providers and assign them to the sites which consume them. 

This infrastructure powers features like support for multisite and user groups. By default, when a site administrator creates a new site, Sitefinity CMS creates a new, dedicated source (powered by a virtual provider) for each enabled module (an instance of a specific Manager). However, the site administrator can select multiple sources to be enabled for a given Module, thus enabling sharing of content between multiple sites. Underneath, Sitefinity CMS creates the relevant providers and connects them to the managers.