I know what is the best way to develop a multi-ORM solution.
So far I have seen projects related to the choice of ORM loudly and they remain with it till the end. Nhibernate, Castle ActiveRecord, Linq to SQL, WilsomorM, LLBLGen, Subsonic, Entity Framweork, others ... I was wondering if I want to or not, the strong relationship of this option with the rest of the different project . The way I wanted to whenever I could change the ORM
Now the only idea for me is that I got something like "factory" and I found the ORM object and then I got it something "internal "Will map to the object.
When a project starts with some boundaries and decisions made at that time, do not give any other option in choosing a specific ORM or some other goods in a specific area.
But in later times, months, years or so, many things change, more money, more support, advances in technologies, new frameworks / ideas, etc ... give us better options, And in this situation it would be really good to be able to change the ORM without making major changes in application (at this time a big one can be).
I want to know your opinion.
Thanks guys.
Changing your ORM is always a time-consuming process, as the abstract provided by ORM always comes with blood in your code, even if you do not realize it: ORM's features (or lack of some features!) Will appear in your code. Choosing a linq-based ORM makes it easy to switch because the question can be transferable to another ORM (if it supports linq too), it would be easy. But this will be a lot of work, so the rich feature to choose an ORM is wise.
Another issue is the mapping definition, the model itself: converting one into another is difficult, if not impossible, without proper tooling, if you see a designer like LLBLGen Pro v3 () So you can use the same project, mapping and switching with same unit model and different ORM is easy (you still have to update your own course).
(Disclaimer: I'm the key developer of LLBLGen Pro.
Comments
Post a Comment