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:

• DotNetNuke Architecture - Digging Into the DNN Source Code
• Community Server Source Code - Abstract Classes, Reflection and Data Providers

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