As a guy who started programming back in the days of DAO, I have nothing but love for ADO.NET. But let’s face it, you can still end up writing pretty lousy code with it. Not everybody’s fully aware of the best uses of the ADO.NET. One of the most common problems I keep stumbling onto in other peoples code is the poor use of ADO.NET Connection Pooling feature.

Somewhere, down the line Microsoft probably started noticing that their cool new data access model wasn’t being fully utilized. The birth of the Microsoft Enterprise Library was probably due to this.

As cool as the Enterprise Library is, I’ve found it to be an over kill for most of my projects. In fact one of my favorite projects featured on CodeProject, was because Enterprise Library’s Offline Application Block was so clunky (and very limited).

Around the same time that I worked on on the SCOAB (Smart Client Offline Application Block), I also wrote a ADO.NET wrapper similar to the Enterprise Library. It pretty much follows the public interface of the Enterprise Library, but it’s a very tiny wrapper compared to the enormous DAAB (Data Access Application Block).

You can download the .cs file here: AbstractDatabase.zip (1.88 kb)

This contains a generic abstract base class called AbstractDatabase. You can extend this class to use it with any type of relational database type. If you take a look at my SQLite Membership Provider, you’ll find this class derived to be used with SQLite ADO.NET Wrapper. I have simply called that class Database, and it’s code looks something like this:

public class Database : AbstractDatabase<SQLiteConnection, SQLiteCommand, SQLiteDataAdapter>
{
    protected override string  GetConnectionString()
    {
        return string.Format(ConfigurationManager.ConnectionStrings["BlogEngine"].ConnectionString,
                            HttpContext.Current.Server.MapPath("~/App_Data"));
    }
}

As you see, the only member you need to override is the GetConnectionString() method. This brings up the question as to why I made this abstract. Why not read the connection string value from the web.config? Well, I’ve done this because I use this class on both web and desktop projects. And in some cases, especially with WinForms applications, the database is SQLite and resides in the application directory. When that happens, I can always hard code the database file name.

Here’s a example of the the Database class’s usage (taken from the SQLiteBlogProvier class).

using (Database db = new Database())
    using (DbTransaction txn = db.BeginTransaction())
    {
        // SQLite doesn't support TRUNCATE
        DbCommand cmd = db.GetSqlStringCommand("DELETE FROM be_Settings"); 
        db.ExecuteNonQuery(cmd, txn);

        cmd = db.GetSqlStringCommand(
                    "INSERT INTO be_Settings (SettingName, SettingValue) VALUES (@name, @value)");
        db.AddInParameter(cmd, "@name", DbType.String, "");
        db.AddInParameter(cmd, "@value", DbType.String, "");
        
        foreach (string key in settings.Keys)
        {
            cmd.Parameters[0].Value = key;
            cmd.Parameters[1].Value = settings[key];
            cmd.ExecuteNonQuery();
        }
        txn.Commit();
    }

A quick rundown of the public interface of AbstractDatabase class:

void AddInParameter(System.Data.Common.DbCommand, string, System.Data.DbType, object)
void AddInParameter(System.Data.Common.DbCommand, string, System.Data.DbType, int, object)
DbTransaction BeginTransaction()
void Dispose()
DataSet ExecuteDataSet(System.Data.Common.DbCommand)
int ExecuteNonQuery(System.Data.Common.DbCommand)
ExecuteNonQuery(System.Data.Common.DbCommand, System.Data.Common.DbTransaction)
DbReader ExecuteReader(System.Data.Common.DbCommand)
ExecuteReader(System.Data.Common.DbCommand, System.Data.CommandBehavior)
T ExecuteScalar<T>(System.Data.Common.DbCommand, T)
abstract string GetConnectionString()
DbCommand GetSqlStringCommand(string)
DbCommand GetSqlStringCommand(string, params object[])
DbCommand GetStoredProcedureCommand(string)
Connection { get; }

Update (June 20, 2008): I have updated this class with a minor bug fix and have added support for other parmeter types including Output and InputOuput parameters (Thanks Yordan).

Update (Oct 20, 2008): This wrapper has been updated and made a part of the Codoxide Common Library