Question

Let just say I have the following data models:

public class Account
{
   public string Username { get; set; }
   public string Password { get; set; }
}

public class Configuration
{
   public string Key { get; set; }
   public string Value { get; set; }
}

For now, each of them has their own repository for data access, and uses entity framework as its unit of work/DbContext. I’m planning to pull out the Configuration part out of the entity frame and use Redis or Memcached as its data access. I might even to switch the EF to NHibernate or no ORM at all, and I might switch the database to MongoDB or CouchDB.

What is the good way to do this? To be ignorant of all those lower layer stuff in my business logic? What kind of pattern to use? Is it possible or is it just bad things to design for changes like this?

Thanks 🙂

Answer 1

As stated in the previous post, you should go the “way of the Interface”.
I personally do not implement directly the repository for each orm but I use a little variation.
Using your example…

public interface IAccountRepository
{
  Account Get(int id);
  void Delete(int id);
  ...other method...
}

then you create your repository

public class AccountRepository : IAccountRepository
{
   private readonly IUnitofWork unitofWork;

   public AccountRepository(IUnitofWork unitofWork)
   {
      this.unitofWork = unitofWork;
   }

   //Implement interface method
   public Account Get(int id)
   {
      //some logic or just the call to the unit of work
      return unitofWork.Get(id);
   }
}

I am happy with this solution because I end up with only one repository that 90% of the time use linq to query so I don’t have to write the sql for each unit of work and every time I have to write a “GetAllProducts” with paging I do not have to write the same code (and tests) for every unit of work, but only for my repository. This is a simple example obviously so I hope you get the idea.
You can make a RepositoryBase that implement a method Find() or Query() which use linq.
Then with your Castle Windsor or ninject or whatever you can inject the unit of work you prefer. Hope it helps.

Update:
a sample of my UnitofWorkBase that implement nhibernate is something similar:

public class NHUnitofWork<T> : IUnitofWork<T> where T : EntityBase
{
protected INHSessionBuilder SessionBuilder { get; private set; }

public NHPersistorBase(INHSessionBuilder sessionBuilder)
{
  SessionBuilder = sessionBuilder;
}

public T Get(int id)
{
  T result = null;
  ISession session = SessionBuilder.GetSession();
  using (ITransaction transaction = session.BeginTransaction(System.Data.IsolationLevel.ReadCommitted))
  {
    try
    {
      result = (T)session.Get(typeof(T), id);
      transaction.Commit();
    }
    finally
    {
      if (transaction.IsActive)
        transaction.Rollback();
    }
  }
  return result;
}
public IQueryable<T> Find()
{
  return SessionBuilder.GetSession().Query<T>();
}

}