Repository Pattern with Multiple ORM

Question

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.

Answer 1

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.

Answer 2

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.