Chris Rauber - Using Miado

this.Blog.Find(entry => entry.IsHelpful);

Sunday, February 15, 2009

Using Miado – Part 1

I released a new version of Miado on CodePlex last night, so I thought I’d spend a couple of blog posts explaining how to use the API. Consider this post as the first in a multi-part series on how to use the newest version.

Basics – Creating an IDatabase

The first thing you need to do is get a handle on an IDatabase. The interface (and its corresponding implementation) serves as the entry point of the API. Obviously, the easiest way to do so would be to directly new one up. The Database constructor takes in a DbProviderFactory object and a connection string.

  1: string connString = 
  2:     "Data Source=localhost;Initial Catalog=MyDatabase; User ID=MyUser; Password=Password1";
  3: IDatabase db = new Database(SqlClientFactory.Instance, connString);

I’ve created a few sub-classes of the Database class that take care of the provider initialization (using the corresponding DbProviderFactory implementations provided in the .Net Framework) and just take in a connection string:

OdbcDatabase
OleDatabase
OracleDatabase
SqlServerDatabase

e.g.

  1: string connString = 
  2:     "Data Source=localhost;Initial Catalog=MyDatabase; User ID=MyUser; Password=Password1";
  3: IDatabase db = new SqlServerDatabase(connString);

Using Miado with a Depedency Injection Container

I’m a big fan of Dependency Injection, so I normally create a reference to the IDatabase in my application start event and store it in the DI container.

  1: public class Global : System.Web.HttpApplication, IContainerAccessor
  2: {
  3:     public IUnityContainer Container 
  4:     {
  5:         get;
  6:         protected set;
  7:     }
  8: 
  9:     protected void Application_Start()
 10:     {
 11:         this.InitializeContainer();
 12:     }
 13: 
 14:     protected void InitializeContainer() 
 15:     {
 16:         var container = new UnityContainer();
 17:         
 18:         string connString = ConfigurationManager.ConnectionStrings["MyDatabase"].ConnectionString;
 19:         // create IDatabase instance and store it in the container
 20:         var db = new SqlServerDatabase(connString);
 21: 
 22:         container.RegisterInstance<IDatabase>(db);
 23: 
 24:         // create a Repository object - IDatabase will injected in it
 25:         container.RegisterType<IUserRepository, UserRepository>();
 26: 
 27:         // rest of the container initialization omitted ...
 28: 
 29:         Container = container;
 30:     }
 31: }

When I create my repository objects, I design them to take a reference to the IDatabase in the constructor.

  1: public class UserRepository : IUserRepository
  2: {
  3:     public UserRepository(IDatabase db)
  4:     {
  5:         this.Database = db;
  6:     }
  7: 
  8:     public IDatabase Database 
  9:     {
 10:         get;
 11:         private set;
 12:     }
 13: 
 14:     // CRUD methods omitted
 15: 
 16: }
 17:

The nice thing about the DI container is that it will automatically inject a reference to the IDatabase instance I registered when it resolves the Repository reference.

  1: IContainerAccessor accessor = HttpContext.Current.ApplicationInstance as IContainerAccessor;
  2: 
  3: // IDatabase is resolved and injected in UserRepository constructor
  4: IUserRepository userRepository = accessor.Container.Resolve<IUserRepository>();

If you don’t want to use a DI container, you can accomplish a similar de-coupling by hiding the IDatabase creation behind a Factory object.

  1: public static class DatabaseFactory 
  2: {
  3:     private static readonly IDatabase _db = 
  4:         new SqlServerDatabase(ConfigurationManager.ConnectionStrings["MyDatabase"].ConnectionString);
  5: 
  6:     public static IDatabase CreateDatabase() 
  7:     {
  8:         return _db;
  9:     }
 10: }