Creating an Abstraction Layer Over the ORM Layer

databaseorm

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.

Best Answer

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.

Related Topic