We are developing the application with MVC and Repository Pattern. Currently we are using EF as an ORM. But Later we need to change the ORM to nHibernate. Any Idea on the architecture.

Currently I plan the architecture as

  1. Contracts: Model/Entities/Repository-Interface/Service-Interface
  2. DataLayer(Reference Contracts) Repository Implementation
  3. Service Layer(Reference contracts, DataLayer) Service Implementation
  4. Web (Reference Contracts,ServiceLayer) Implement Dependency injection (Unity)

Here the DataLayer is tightly coupled. So I need to break and make like this

  1. Contracts: Model/Repository-Interface/Service-Interface
  2. DataLayer(Reference Contracts) Entities/Repository Implementation (which will return Models)
  3. Service Layer(Reference contracts, DataLayer) Service Implementation
  4. Web (Reference Contracts,ServiceLayer) Implement Dependency injection (Unity)

Whether above will work if we change the ORM, or it will have major impact.

  • 1
    Why do you need to change the ORM?
    – Mr Cochese
    Nov 4, 2016 at 13:38
  • @MrCochese N-hibernate is need to replace EF since it can handle large data sets which are synchronized using Session.
    – Ram kumar
    Nov 4, 2016 at 13:40
  • 1
    Why don't you switch to NHibernate just once and forget about EF?
    – Doc Brown
    Nov 4, 2016 at 14:35

2 Answers 2


If I were your boss I wouldn't let you come up with an architecture that allows to swap out ORM. I would pick an ORM and live with it because switching it out would be too much work and would cost time and money with very little benefit.

In this case, I would use the ORM that meets your requirements, which in this case according to what has been stated is nHibernate. If you have already invested time and effort into Entity Framework and it is too late to reverse course, then I would write a custom implementation to handle the large data set case and continue on using Entity Framework to handle the other majority of data access scenarios.

  • 1
    Exactly my thoughts, building a system to switch between ORMs looks more like a task for an architecture astronaut
    – Doc Brown
    Nov 4, 2016 at 14:38
  • @DocBrown I agree. Though it's amusing that Joel's example of a stupid thing that nobody needs is cloud-based, accessible-anywhere file storage.
    – user82096
    Nov 4, 2016 at 14:45
  • @Jon, Its is multi tenant application so it can change to nhibernate, So any ideas on the implementation. Models will not change only instead of EFUOW and EFRepository i need to use NHUOW and NHRepository
    – Ram kumar
    Nov 4, 2016 at 15:00
  • 1
    @Ram - Well my pragmatic answer aside, you would have to build out another abstraction so that the ORM is abstracted away. Maybe an interface called IObjectRelationTool to start with. Then you would have a EF tool implementation and a nHibernate tool implementation.
    – Jon Raynor
    Nov 4, 2016 at 15:08
  • @Jon, Any implementations on abstract ORM. Or I can create Repository Layer which will have entities,Interfaces, Repository impelentations where the repository will use DTO(which entity is convert as model and vice versa)
    – Ram kumar
    Nov 4, 2016 at 15:13

Make the simplest PoC as you can with, say, half a dozen domain objects, just one repository, and one service layer, with strict POCOs (code first with EF), no EF-specific custom attributes. Same with NHibernate.

Make sure to have a many-to-one and a many-to-many relation somewhere.

Then, notice how hard it is to not depart from those POCOs without having to rely on EF or NHibernate specifics to implement the same eager or lazy loading semantic, for whatever consumption use cases in your service layer in both ORMs.

Do not cheat. Write the same unit tests against each to have, if not a formal proof, at least more evidence whether the code behaves the same in both version.

Take note of each and every point where you have to rewrite towards custom NHibernate-this or custom EF-that, to finally have the same unit tests give the same answers (all other things considered equal).

Try to recognize all the boilerplate patterns that emerged, and made the EF POCOs and repo deviate from their NHibernate counterparts, or the other way round, and start thinking of those patterns in terms of the source model that a (hypothetical) code generator X-to-EF + X-to-NHib would feed on.

By then, you should have a better idea of what your question actually implies wrt. some hypothetical future effort in that direction.

Your Answer

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

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