That way lies madness. It is highly unlikely that you would ever need to change ORMs. And if you ever decide to change the ORM, the cost of rewriting the mappings will be a tiny fraction of the cost to develop and maintain your own meta-ORM. I would expect that you could write a few scripts to do 95% of the work needed to switch ORMs.

In-house frameworks are almost always a disaster. Building one in anticipation of future needs is almost a guaranteed disaster. Successful frameworks are extracted from successful projects, not built ahead of time to meet imaginary needs.

The ORM provides an abstraction for your data layer to be independent of its RDBMS, but it may not be enough to “untie” your business layer from your data layer. Specifically, you should not let objects that map to RDBMS tables to “leak” directly into the business layer.

At the very least, your business layer needs to program to interfaces that your ORM-managed, table-mapped objects from the data layer could potentially implement. Additionally, you may need to create an interface-based layer of abstract query building to hide the native querying capabilities of your ORM. The main goal is to avoid “baking in” any particular ORM into your solution beyond its data layer. For example, it might be tempting to create HQL (Hibernate Query Language) strings in the business layer. However, this seemingly innocent decision would tie your business layer to Hibernate, thus nailing the business and the data access layers together; you should try to avoid this situation as much as possible.

EDIT : In your case, the additional layer inside the repository is a waste of time: based on your point number two, your business layer is sufficiently insulated from your repository. Providing additional insulation would introduce unnecessary complexity, with no additional benefits.

The problem with building an extra abstraction layer inside your repository is that the particular “brand” of ORM dictates the way you interact with it. If you build a thin wrapper that looks like your ORM, but is under your control, replacing the underlying ORM will be roughly as hard as it would be without that additional layer. If, on the other hand, you build a layer that does not look anything like your ORM, then you should question your choice of the object-relational mapping technology.

The UnitOfWork usually provides this abstraction. It’s one place that needs to change, your repositories depend on it via an Interface. If you ever need to change O/RM, just implement a new UoW over it. One and done.

BTW it goes beyond just switching O/RM, think of unit testing. I have three UnitOfWork implementations, one for EF, one for NH (because I actually DID have to switch O/RMs mid-project for a client who wanted Oracle support), and one for InMemory persistence. The InMemory persistence was perfect for unit testing or even for rapid prototyping before I was ready to put a database behind it.

The framework is simple to implement. First you have your generic IRepository interface

public interface IRepository<T>
  where T:class
{
  IQueryable<T> FindBy(Expression<Func<T,Bool>>filter);
  IQueryable<T> GetAll();
  T FindSingle(Expression<Func<T,Bool>> filter);
  void Add(T item);
  void Remove(T item);

}

And the IUnitOfWork interface

public interface IUnitOfWork
{
   IQueryable<T> GetSet<T>();
   void Save();
   void Add<T>(T item) where T:class;
   void Remove<T>(T item) where T:class;
}

Next is the base repository (your choice on whether or not it should be abstract

public abstract class RepositoryBase<T>:IRepository<T>
  where T:class
{
   protected readonly IUnitOfWork _uow;

   protected RepositoryBase(IUnitOfWork uow)
   { 
      _uow=uow;
   }

   public IQueryable<T> FindBy(Expression<Func<T,Bool>>filter)
   {
      return _uow.GetSet<T>().Where(filter);
   }

   public IQueryable<T> GetAll()
   {
      return _uow.GetSet<T>();
   }

   public T FindSingle(Expression<Func<T,Bool>> filter)
   {
      return _uow.GetSet<T>().SingleOrDefault(filter);
   }

   public void Add(T item)
   {
      return _uow.Add(item);
   }

   public void Remove(T item)
   {
      return _uow.Remove(item);
   }
}

Implementing IUnitOfWork is child’s play for EF, NH, and In Memory. The reason I return IQueryable, is for the same reason, Ayende mentioned in his post, the client can further filter, sort, group, and even project the result using LINQ and you still get the benefit of it all being done server side.