text: I remember when the provider model first came out and how I latched onto it like a duck on a june bug :) Many of the applications delivered to customers soon after its introduction used the provider model, especially for the data access layer. The posts about it are still there on my blog as a reminder:
  However, somewhere down the line I stopped using it, and I can't remember why.
  This morning I wanted to whip up a sample using it to compare it to some of the other alternatives I have been talking about lately: SubSonic, Castle Project's ActiveRecord, Web Service Software Factory and the Data Access Guidance Package, etc.
  Where are the Templates?
  I remember there being some templates to help with the creation of custom providers and after a bit of searching I finally found the Provider Toolkit. When you download it, you are essentially getting a few templates to include in your application:
  One of the nice things that ReSharper does is gray out variables not being used in the code. I was rather surprised to see that the ProvideManager Class shown above has 3 variables not being used in the code. Makes you wonder why they are in the template, but there may be some good reason:
  The Project
  I put together a mythical blog framework using the Provider Model for the pluggable data access layer.
  The DataProvider Class is an abstract class defining all the data access methods:
  public abstract class DataProvider : ProviderBase
  {
  //Methods
  public abstract Blog GetBlogByBlogId(int blogId);
  public abstract void InsertBlog(Blog blog);
  public abstract void UpdateBlog(Blog blog);
  public abstract void DeleteBlogByBlogId(int blogId);
  }
  and SqlDataProvider is the concrete class that implements them:
  public class SqlDataProvider : DataProvider
  {
  private String connectionStringName;
  public override Blog GetBlogByBlogId(int blogId)
  {
  IDatabase database = DatabaseFactory.CreateDatabase(connectionStringName);
  BlogDAO dao = new BlogDAO(database);
  return dao.GetBlogByBlogId(blogId);
  }
  ...
  }
  All requests pass through a manager class that delegates operations to the default provider, SqlDataProvider in this case.
  public class DataServices
  {
  ...
  public static DataProvider Provider
  {
  get
  {
  return defaultProvider;
  }
  }
  ...
  public static Blog GetBlogByBlogId(int blogId)
  {
  return Provider.GetBlogByBlogId(blogId);
  }
  }
  Your config file has the list of providers as well as specifies the default one:
  <configSections>
  <section name="DataProvider"
  type="MyBlog.Framework.DataProviderConfiguration, MyBlog.Framework"
  allowDefinition="MachineToApplication" />
  </configSections>
  <DataProvider defaultProvider="SqlDataProvider">
  <providers>
  <add name="SqlDataProvider"
  type="MyBlog.DataProviders.SqlDataProvider, MyBlog.SqlDataProvider"
  connectionStringName="ConnectionString"
  description="SQL Server Data Provider" />
  </providers>
  </DataProvider>
  Pretty straight forward and a fairly easy, built-in way to provide a pluggable architecture.
  Love It, Hate It, Or Indifferent?
  I am curious if people are using the custom provider model and/or the provider toolkit for their applications. Has it lived up to the hype? Do you love it or hate it or have any opinion on it whatsoever? Is there an alternative that you find works better?
  by David Hayden
  [Advertisement]
  I like it, and use it sometimes. My problem is working on inward only - stable systems I don't have much use for provider models at the moment.
  As long as there is no native MicroKernel support in the Netframwork (Object Builder is still beta) I try to use it where ever it is possible in combination with CFD!
  One way or another you have to compare the Provider model to the DI/IoC frameworks. I'm biased, but I think the IoC tools are easier to use, more flexible, and give you much looser coupling than the Provider model.
  I don't find the ASP.NET Providers to necessarily conflict with good designs, like DI/IoC or O/R Mapping. Of course the default implementations are very poor designs with their intermixing of the logical layers, but that doesn't imply our implementations have to be this way. I actually have my custom implementations that rely on my WilsonORMapper and they are extremely simple, and work with any database. I've got a simple version that I use in presentations, available at, and my WilsonWebPortal uses the full versions, which are more complete and far more optimized.
  Paul,
  I'm not saying that the Provider model conflicts with good design, just suggesting that the OSS DI tools might be a simpler, better implementation of the Plugin pattern than the Provider model.
  One problem/issue/concern that I see about Provider Model for DAOs is that DAOs are exhausted of their single inheritance. It may be good/bad thing based on composition of development team.