Multi ORM solution

Question

Hello,

I would like to know what's the best way to develop an multi ORM solution.

Until now all the projects I saw are strongly related with the choice of ORM and they stick with it until the end. Nhibernate, Castle ActiveRecord, Linq to SQL, WilsomORM, LLBLGen, SubSonic, Entity Framweork, others...

I was thinking if I should or not, separate the strong relation of this choice with the rest of the project. In a way where I could change the ORM anytime I wanted.

For now the only idea that I've is something like "factory" retrieving me the ORM object and then I would map it to some "internal" object.

There are situations when a project start with some limitations and the decisions made on that time, don't give any other option than choosing one specific ORM or some other stuff in a different area.

But later in time, months, year, or so, many thing change, more funds, more support, advance in technologies, new frameworks/ideas, etc... provide us with better options, and in this situation it would be really cool to be able to change the ORM without major changes in the application (in this time can be HUGE one).

I would like to know your opinions.

Thank you guys.

Answer 1

Changing your ORM is always a time consuming process, as the abstraction provided by the ORM will always bleed into your own code, even if you don't realize it: the features (or lack of some features!) of the ORM will be visible in your code. Choosing a linq-based ORM will make it easier to switch as queries might be transferable to another ORM (if that one also supports linq) easier. But it will be a lot of work, so choosing an ORM up front which is feature rich is wise.

Another issue is the mapping definitions, the model itself: converting one into another is difficult, if not impossible, without proper tooling. If you look at a designer like LLBLGen Pro v3 (http://www.llblgen.com) you can use the same project, the same entity model and mappings with different ORMs and switching is easy (you still have to update your own code of course).

(Disclaimer: I'm the lead developer of LLBLGen Pro.

Answer 2

IMHO this would always be a hard core solution. Mapping ORM classes with some internal ones will always lead to "double work" and problems. Some DB schema change will require changes once again in this mapping class, for some reason this will demand extra attention to not be forgotten.

Also other things to have in mind: transactions, lazy loading, for some reason some ORM behave differently from others, or have or not that functionality. Assuming that all are similar is not correct. Taking this in consideration, I think, this isn't so trivial to do.

Answer 3

Changing Your ORm maybe Cause Changing Your Data Access Layer. And Every ORM has its own Schema For Generating Codes. I am Agree With Frans Bouma. ((Choosing a linq-based ORM will make it easier to switch as queries might be transferable to another ORM (if that one also supports linq) easier)) and you Can Develop your OWn ORM and able it to Generation LINQ queries For it! can ?! Good luck