In a nutshell, the provider model is a design pattern largely used by Microsoft components for allowing an application to make use and choose from multiple implementations of a given contract based on the settings of a configuration file. So, for instance, management of user membership or roles are usually carried out by means of classes based on this pattern (see MemberShipProvider or RoleProvider classes). This way, the application can choose the default provider for dealing with membership or roles, add or remove providers, etc. in a declarative way. It brings a lot of benefits for developers as they can plug new components easily without refactoring code.
In the Microsoft world, providers must inherit from
ProviderBase abstract class (
System.Configuration.Provider namespace in
Derived provider classes are configured in a declarative way within a proper
web.config file according to the type of application we are working with. So, we need some rules to write these settings and some classes to read data accordingly. We can implement all of this with a
ProviderConfiguration class able to read collection of providers and details for each one. On the other hand, the way for writing data in config files can be carried out by means of
<configSections /> node in the
app.config displayed at the bottom).
As said before, if we are going to deal with multiple providers we need an object to store the list of providers. This can be achieve with a
ProviderCollection class holding the list of configured providers.
Finally, we need a
LogProviderManager class able to:
- Read and expose all the configuration data by using the
- Instantiate and expose the list of providers by placing them in a
- Expose the default provider by some public default property.
Let's suppose we need to provide options for logging information in plain text or xml depending on application requirements. It would be a very good case to implement it by using the provider pattern. Not only developers would be able to choose between these implementations but they could create new ones as well and plug them very easy. See the class diagram displayed below:
LogProviderManager class instantiates the
LogProviderCollection based on the configuration settings exposed by
LogProviderConfiguration class. The default provider along with the collection of log providers are exposed by
LogProviderManager by means of properties
LogProviderManager exposes the
ProviderSettingsCollection by means of
Here is the
app.config file for more clarification:
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
Notice that configuration of providers should contain a
name and a
type attribute containing the provider name and the fully qualified class name implementing the provider. The rest of attributes are optional (
fileLocation above) and serve to incorporate values for new customized provider properties. They will be returned in a
System.Collections.Specialized.NameValueCollection property for each
ProviderSetting object within
ProviderSettings collection property in
Having said that, all developers have to do is to use the
LogProviderManager.Default property to get an instance of the default provider and then, call the exposed methods on it.
Please, take a look at here for accessing the original post from which this one was written. You can also download the source code from there.