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:
- 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.
- 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.
- 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.