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?


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.
  • 3
    extra layer needs justification, otherwise it violates YAGNI. In other words, someone believing that you need it, has a burden to prove that
    – gnat
    Oct 19, 2012 at 18:10
  • 2
    I can understand wanting a domain layer that only exposes a wanted subset of operations - ORMs tend to be a bit too wide a surface area (say you don't want to allow updates to an entity not directed by another containing entity). Having such a layer of abstraction helps with this.
    – Oded
    Oct 19, 2012 at 18:14
  • 5
    You'll probably need a second layer of abstraction for the first layer of abstraction above the ORM just in case you want to change the first layer too. Oct 19, 2012 at 18:32
  • 1
    @David While we're adding redudancy, change all your if(boolean) to if(boolean == true) and if you'd like to regurgitate more of the same, if (boolean == true == true...) and so forth
    – brian
    Oct 19, 2012 at 18:56
  • 1
    Interesting related post: ayende.com/blog/3955/repository-is-the-new-singleton
    – RMalke
    Oct 19, 2012 at 19:03

3 Answers 3


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.

  • I'm so glad .NET has solved this problem by baking the Query Object into the platform. The .NET port of Hibernate even supports it. Oct 19, 2012 at 18:54
  • 2
    @MikeBrown Yeah, and .NET also supplied two competing ORM technologies of its own, both using the LINQ technology! Oct 19, 2012 at 18:56
  • @dasblinkenlight I updated the question to give you additional information. Oct 19, 2012 at 19:18
  • Lately, I have adopted the approach of having the business layer depend on a data layer based on map-like and set-like interfaces to store state. I now believe those interfaces represent the state-keeping concern well enough (inspired by the functional style of programming) and provide a nice separation from the ORM of choice via a rather thin implementation.
    – beluchin
    Mar 23, 2016 at 11:43

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)

   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.

  • 1
    But the question here is determining whether or not that layer above is useful and should be the gatekeeper to all data access.
    – brian
    Oct 19, 2012 at 18:59
  • Wish I could point to my blog post on the Unit Of Work/ Repository implementation. It discusses the exact concerns from the OP. Oct 19, 2012 at 19:34
  • Giving the layer a name doesn't mean it is necessary or useful. Oct 19, 2012 at 19:35
  • Note according to the OP, he has an extra mapping between data access and business layer. For me, my business objects and entity objects are the same. EF and NH provide amazing mapping APIs such that the data mapping rarely (if ever) becomes a concern. Oct 19, 2012 at 20:08
  • How do you translate an arbitrary Expression to an efficient ORM call? You can't just fetch everything and throw away the rows that don't match the filter. Oct 22, 2012 at 15:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.