Overview: Provider model
This topic provides a high level overview about the Provider model design pattern on which Sitefinity CMS is based.
Purpose of the Provider Model Design Pattern
Several of the built-in ASP.NET features such as Membership, Profiles, 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 only minimal coding and modifications are required. The definition provided by Wikipedia states that: "It [provider model] is used to allow an application to choose from one of multiple implementations in the application configuration, for example, to provide access to different data stores to retrieve login information, or to use different storage methodologies such as a database, binary to disk, XML, etc."
Provider Model in Sitefinity
Everything in Sitefinity CMS is built on the Provider model. Here are a few examples:
- Modules
- Security
- Taxonomies
Provider Model Allows Clear Separation of Responsibilities
From that definition of the Provider model, we know that if something is built on that model, it allows multiple / different implementations. This means that one could implement a provider for Blogs module that would, 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).
Let us first look at a real life provider model. 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).
Here is another interesting point to take from this analogy. 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.
Sitefinity CMS Supports Multiple Providers
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.
