Attention: We are retiring the ASP.NET Community Blogs. Learn more >

System.Configuration.Provider.ProviderBase

The provider pattern is a new "specification" which is appearing in Whidbey and is all about giving flexibility and choice by not locking users into a limited set of choices or implementations.  You can read Rob Howard's article about it here:

    Provider Model Design Pattern and Specification, Part 1
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp02182004.asp

In the past people have resorted to "rolling their own" API logic where existing platforms have failed to meet a need. An example of this is page templating - just about everybody has implemented their own page templating system but, unfortunately everybody has implemented in using different interfaces and different logic.  A downside to this is that, new developers have trouble in understanding how it "hangs" together because the API may "feel" unfamiliar to what they have used in the past.

The Provider pattern is ...
 
    "given the name 'provider' since it provides the functionality for an API"

ProviderBase is the base class from which all Providers derive - this class is used to explicitly mark a class as a "Provider".  Once a problem has been identified for which a provider can be written a more specialized class is derived from ProviderBase to provide a starting point for the new set of providers.  Using the example from Rob's article, the Membership classes use providers which all derive from MembershipProviderBase.  Once you've got your specialized base class defined you can then layer it with specific implementations such as: SqlMembershipProvider, AccessMembershipProvider or FileMembershipProvider.

Another example might be if you decided to implement logging in your application and you wanted the ability to extend in the future you could create an abstract LoggingProviderBase class and then define specific logging implementations as you saw fit... SqlLoggingProvider, AccessLoggingProvider or FileLoggingProvider and so on.  You can then create a Logging class which uses the configured LoggingProvider class to do it's logging operations via the LoggingProviderBase interface.

While this model is by no means new, the formalization and wide ranging use of it by the ASP.NET team will ensure that there is a new move to adopt its usage and you can expect to see more and more chunks of functionality move to this pattern as time goes by.

2 Comments

  • Just as an FYI for a resource on provider patterns. DotNetNuke (www.dotnetnuke.com) uses the provider pattern for the data abstraction layer. This enables developers to design multiple access classes for each specific database. Since the provider is an abstraction class within DotNetNuke, the core code doesn't need to change or really care about whether or not you changed the database. So if you want to see provider patterns in practice I'd recommend downloading DotNetNuke and checking out the database provider.

  • Also, it's going to take a LOT more work than that to create your own Provider Model API. I built mine exactly like the architecture for Whidbey on .NET 1.1, and complete implementation weighs in at over 2000 lines of code.



    There are a few gotchas with the current Whidbey build as well. The class that manages Provider instantiation, System.Web.Configuration.ProvidersHelper, is sealed. Meaning that if you want to initialize your providers, you'll have to roll your own solution. Hopefully I'll be able to convince Microsoft to fix that before RTM.

Comments have been disabled for this content.