.Net Provider Pattern – Designing decoupled and extensible Component for .Net Application

Provider design pattern of .Net Framework 2.0 facilitates an approach to design components in a decoupled and extensible manner. In this post, we investigate this design pattern, and show how we can utilize it to make components decoupled while providing extension points for configuration. To do so, we present the outline of today’s discussion as follows-–


  1. What is Provider Design Pattern?
  2. Walkthough: Using Provider Pattern

  3. Advantages
  4. Conclusion

What is Provider Design Pattern?

Provider pattern is a way in .Net Framework 2.0 to design extensible and decoupled Component. Ron Howard mentioned –

“A provider is simply a contract between an API and the Business Logic/Data Abstraction Layer. The provider is the implementation of the API separate from the API itself.”

Provider pattern is a way to get rid of the coupling among the components while making the components extensible. Main reason for our today’s discussion on Provider Pattern is its wonderful ability to publish the API and at the same time make the API pluggable; that is– it gives us the flexibility to choose the API that is best suited for the application rather than the one developed by API developer. And from an API developer perspective, it allows them to create an extension point for the API where clients of the framework can extend the functionality in their own way.

In the next section, we walk-through an example, which builds a component using provider design pattern.

Provider Pattern in Action

The basic idea behind the provider pattern is to have multiple ConcreteProviders and selecting one of them depending on configuration (just a change in ‘*.config file can lead to completely different provider to perform the operation) at the runtime by avoiding writing huge amount of code and coupling among the components. Provider pattern completely abstract the decision of which provider to use out of programming interface. That way we can say that, it has some kind of dependency injection/inversion flavor, but it does not use any kind of container like Windsor or Spring.net.

We first consider a simple and contrived problem (designed only for illustrative purpose), which is used throughout today’s discussion. We have the following simple domain object: User and we need a persistence media to store(/Save) and retrieve(/Get) it.

User class

This class is responsible for communicating with the physical persistence media. PersistenceManager has only two jobs.

  1. public static void Save<T>(T obj)
  2. public static T Get<T>()

Consider that this implementation as of now only supports two persistence media: SQL Server2005 and Xml (via File system). Depending on the clients’ need, we will be using any one of them at the runtime, keeping in mind that in future client might use some other persistence media like Oracle, mySql or whatever.

If we are not familiar with provider pattern, we would solve this problem using any dependency injection container (e.g. Windsor/Spring.Net/Unity), or introducing factory method to instantiate the desired component at the runtime; that is, either we had to introduce new code (write and manage) or new vocabulary to grasp (with dependency injection container) while providing custom solution. Truly that would be an overhead if we would like to solve only this problem. Then, why do we not use something from .Net2.0 when it is providing it (e.g. as in Asp.net Membership)?

A solution with .Net provider design pattern consist of following basic parts–

  1. API class (PersistenceManager) to publish API(save and get). It is also responsible to instantiate a ConcreteProvider depending on the configuration.
  2. Domain specific Abstract Provider (PersistenceProviderBase) a.k.a. Application ProviderBase inherited from ProviderBase class of System.Configuration.Provider namespace.
  3. ConcreteProviders (XmlPersistenceProvider and SqlPersistanceProvider) inherited from domain specific Abstract Provider.
  4. Custom Configuration Section to configure the Providers and a class inherited from ConfigurationSection to represent it in .Net.

The following diagram shows different parts of provider design pattern that we intend to discuss one by one.

Basic parts of Provider Design pattern

We begin with a custom Configuration section.

Custom Configuration Section

In order to make the provider pattern pluggable and flexible, evidently we have to devise a wat to configure the providers at the runtime. Application configuration via .config is probably the best approach to link communication between the available providers and configuration.

To achieve this, we need to add a class inherited from ConfigurationSection to handle the configuration of providers:

Class to store custom Configuration Section

Following is an example of the custom section for the Persistence Provider.

Important attributes to note here:

Indicates the default ConcreteProvider.
Defined to provide extra information needed to the Concrete Provider. For example , XmlPersistenceProvider will save the information about the domain object in the path specified and SqlPersistenceProvider use the value specified as the connection string to the database.

We can also define other attributes as required, which can be used to initialize the ConcreteProvider (e.g. logFilePath). Benefit of such approach is that we can return to this custom configuration, and change ConcreteProvider at the runtime.

Next we move on to explore the PersistenceManager class whose responsibility is to initialize the ConcreteProvider depending on the configuration section and publish the APIs.


PersistenceManager is the major gateway to the concrete provider as I mentioned earlier that it communicates directly with the underlying persistence media using one of the concrete provider to perform the operation (e.g. Save/Get) that it exposes.

Save method of PersistenceManager is outlined as follows.

Get method of PersistenceManager is described next.

If we look at the PersistenceManager closely, the static Instantiate method, that instantiate the provider based on the Configuration from PersistenceProviderConfigSection. In order to do that, we use a built-in support feature of the .Net Framework2.0, which is core to this desing pattern: we will use ProvidersHelper class of System.Web.Configuration namespace. The ProvidersHelper.InstantiateProviders method initializes the ConcreteProviders by calling the Intialize() method of the ConcreteProviders (we come back to this point in the next section again).

Therefore, the DefaultProvider property in PersistenceManager always refers to the default ConcreteProvider specified in the configuration. Another alternative is to use reflection to instantiate ConcreteProvider.

Now, we describes the details of the ConcreteProvider, and how it gets initialized when we call ProvidersHelper.InstantiateProviders(config.Providers, Providers, typeof(PersistenceProviderBase)).

Application ProviderBase and Concrete Providers

In short, Application ProviderBase class or Domain-specific ProviderBase provides the abstract version of the functionality exposed by the API class, and the responsibilities of the ConcreteProviders is to implement those API in their own way. As we can see next figure, our Application ProviderBase- PersistenceProviderBase implements IPersistenceProvider, which describes the API exposed by PersistenceManager class.


ProviderBase class belongs to System.Configuration.Provider namespace, which contains all the member to be implemented by the ConcreteProviders. It contains properties to describe ConcreteProviders, such as, Name and Description. Initialize() is used to initilize providers. PersistenceProviderBase is the mirror of API or services that ConcreteProvider facilitates.

As shown below, two ConcreteProviders extends PersistenceProviderBase and provides implementation of Save and Get specific to the context of a particular provider.

ConcreteProviders and their members

In addition to that, in Initalize() method, concrete providers also initialize associated properties configured through web.config. For instance,

  • _PersistenceMediaPath of the concrete providers will be initialized with the value ofPersistenceMediaConnectionString from web.config.
  • Name and Description will be initialized.

Following code outlines the initialization process of SqlPersistenceProvider.

To illustrate initilization of a ConcreteProvider, we show following snapshot taken from the debug-mode.

init of a concrete provider

After initialization, we are only left with the Provider-specific implementation of the abstract functionality of the PersistenceProviderBase, i.e., Save/Get. Every provider will implement in their own way. For instance, if we consider XmlPersistenceProvider, it will implement the Save/Get method as follows, whereas, SqlPersistenceProvider typically stores and retrieves from Sql Server.


Why would we adopt provider design pattern?– To create loosely coupled components that are extensible from an application perspective.

Revisiting custom ConfigurationSection we have implemented, we set XmlPersistenceProvider as the default PersistenceProvider. If we want to use SqlPersistenceProvider we can simply change in the value of the defaultProvider in the web.config file and our client can start using the SqlPersistenceProvider at runtime.

If requires, any additional provider can simply be added by extending any ConcreteProvider, or by implementing IPersistenceProvider, as shown below.


As in other providers, this new provider can also be configured during run-time as follows.


In this post, we have shown how we can utilize .net provider design pattern to make a component loosely couple and extensible. Note that in the example implementation, we have used ProvidersHelper class of System.Web,Configuration while building the component. However, we can easily get rid of adding reference to System.Web namespace, by implementing ProvidersHelper class; alternatively reflection can be used during instantiation of concrete providers.

We highly appreciate any question or query regarding this post. Thanks!


[R-1: 04-04-2013] Porting this blog-post from its weblogs.asp.net page.


Figuring out different properties of a Image from its URL

Sometimes while working with image, it become necessary to get all the properties of an image. This time, I had to find out all the properties of an Image deployed in a web site.Its interesting- that’s why I wanted to share the small code snippet. For our today’s example – let’s pick this gif from our favorite google.com –

We will find out all the properties from the Image URL.

Something About Bitmap Class of System.Drawing –

It represents the pixel data of the graphics image as GDI+ Bitmap and expose all the attributes related to the Image Graphics. In addition to that, it enables manipulation of the Bitmap and save it as File in different format.

There are many overloaded Constructor in the Bitmap class  which enables to create image object in various way at developers convenience.

Using WebRequest and WebResponse class of we can retrieve the Stream of the Image.

string url = "http://www.google.com/intl/en_ALL/images/logo.gif";  

WebRequest request = WebRequest.Create(url); 
request.Method = "Get";  

WebResponse response = request.GetResponse(); 
Stream stream = response.GetResponseStream();

And then we can just initialize a Bitmap object with the stream that we have just retrieved from the URL.

Bitmap bitmap = new Bitmap(stream);

We are done. :) We can access all the properties exposed by the Bitmap object representing the Image Graphics –


Passing Parameter to a Predicate in .Net2.0

In this post, we will see how to pass parameter to a method representing Predicate. 

Let’s say, we have a collection of SprintBacklogItems and we want to filter all the SprintBacklogItem with Title start’s with, let say “QA” or “Dev Task” depending on a input parameter. Now from the previous post https://adilakhter.wordpress.com/2008/01/11/using-predicate-actor-of-net20/  we know that , predicate only have 1 parameter of type T.


Then, how to pass a input parameter _HeaderToSearch in Predicate?

1. To do that, we need to a new object called ListMatcher –

public class ListMatcher 
       private string _HeaderToSearch; 
       public ListMatcher(string headerToSearch) 
           _HeaderToSearch = headerToSearch; 

       public bool Predicate(SprintBacklogItem item) 
           return item.Title.StartsWith(_HeaderToSearch, StringComparison.InvariantCultureIgnoreCase); 


2. Next , I initialized the ListMatcher object and use the HeaderToSearch  to filter the items- 

ListMatcher matcher = new ListMatcher("QA"); 


Using Predicate & Action of .Net2.0

While I started developing software, I faced this situation over and over again where I had to iterate thorough the whole collection and perform some action on each of the element of the collection or filter elements depending on some logic. It was really annoying to  write same for/foreach loop again and again.

.Net framework2.0 resolve this issue where we can just tell the collection how to filter / how to perform some action on each element of the collection and it take care of the iteration part.  Let’s check out the List<T> Class of System.Collections.Generic and what support it provides –


Huge support for Searching, Sorting and Filtering!!! If we look at the declaration of let’s say – FindAll and ForEach  –

public List<T> FindAll(Predicate<T> match);public void ForEach(Action<T> action);

Here Predicate and Actor are the generic delegate which gives us the flexibility to provide a way to filter the collection or perform action to each and every element of the List. Let’s dig deeper inside them –

Inside Predicate:

Predicate is a Generic Delegate which takes support from the new generic feature of .Net Framework2.0. It is defined –

delegate bool Predicate<T>(T obj)

As per definition of MSDN, Predicate

“represents a method that defines a set of criteria and determines whether the specific object meets this criteria.”

In short, Predicate is just a generic delegate that takes T as object and check whether the object fulfill some criteria and depending on that return true|false.


In this example, by using Predicate, we are going to tell the Collection how to filter and Collection will handle the whole iteration and filtering process –

Let’s say, we have a collection of SprintBacklogItem and we want to filter them depending on there State == Closed, we can do it using predicate –

1. Define a method that represents the Predicate –

private bool HasStateClosed(SprintBacklogItem item) 
            if (item.State == SprintBackLogStatesStrings.CLOSED) 
                return true; 
            return false; 

This method simply checks whether the SprintBacklogItem’s state is closed or not and depending on that , return true or false. Now, if we look at the declaration of the method , we are affirmative that we can use Predicate to represent this method.

2.  Following line of code filters all the closed SprintBacklogItems –

List<SprintBacklogItem> closedItems= _SprintBackLogsItems.FindAll(HasStateClosed);

Inside Action:

Similar to Predicate,

“Action is also one kind of generic delegate which represents a method that take the object as input and perform some operation on that.”

Definition of Action delegate-

delegate void Action<T>(T obj);

From the signature of the delegate, it can represent the method with signature that must have one parameter passed to it and void as return type.

In List<T> , the method represented by the Action delegate takes an input obj and perform actions on that.


In this example, by using Action, we are going to perform some predefined actions( initializing ActualHour = 10) on each elements of the List –

1. Define the method that will be represented by Action –

public void InitActualHour(SprintBacklogItem item) 
            item.ActualHour = 10; 

2. Following line of code initialize all the elements’ Actual hour to 10 of the List –


Isn’t it pretty cool and slick ? Instead of implementing methods for Actor and Predicate , we could have used Anonymous Delegate. I will cover that topic in my future posts. Bye for now. :)