Creating a layer of abstraction over the ORM layer

Question

I believe that if you have your repositories use an ORM that it's already enough abstracted from the database.

However, where I am working now, someone believe that we should have a layer that abstract the ORM in case that we would like to change the ORM later.

Is it really necessary or it's simply a lot of over head to create a layer that will work on many ORM?

Edit

Just to give more detail:

1. We have POCO class and Entity Class that are mapped with AutoMapper. Entity class are used by the Repository layer. The repository layer then use the additional layer of abstraction to communicate with Entity Framework.
2. The business layer has in no way a direct access to Entity Framework. Even without the additional layer of abstraction over the ORM, this one need to use the service layer that user the repository layer. In both case, the business layer is totally separated from the ORM.
3. The main argument is to be able to change ORM in the future. Since it's really localized inside the Repository layer, to me, it's already well separated and I do not see why an additional layer of abstraction is required to have a "quality" code.

Answer 1

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.

Answer 2

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.

Answer 3

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.