Must developers care about possibility of changing ORM in future?

Let's imagine I start to develop a project. So must I seriously care about possibility of changing ORM in future?

Or, more precisely:

1. Would you like to change the ORM you use in your current project to some different one. If yes, what a开发者_StackOverflow中文版re the reasons?
2. Have you ever practically did this? If so, what were the reasons?

Speaking practically, I'm thinking if it is valuable to dedicate significant efforts on trying to develop ORM-agnostic solutions, or not.

---

The odds of changing your ORM during the course of the project are pretty low. There is a very good chance that any effort you make to ensure that you can switch your ORM will be wasted in the end. You have to weigh up the the slight possibility of changing the ORM against the extra effort to make it possible to change the ORM.

To answer your questions:

1. No
2. Usually you would change your ORM if there is some substantial need not being met by the tool your are using. I can't really think of any example where this would make sense tho - usually you can get around any issues like these.

At the end of the day I would simply make sure that I choose an ORM that will work for me (can't really go wrong with something like NHibernate) and make sure your code is loosely coupled which should ensure that your data access code is isolated. This is good not only from a maintainability perspective, but also for testability.

---

Yes, I think you should care about it, to what degree is a completely subjective matter. All layers of your application should be given consideration, especially if you believe your code will be in place for any significant amount of time, or if you believe your application will have significant growth.

As far as your specific questions:

1. I have a few projects which use various different storage systems and frameworks for managing data and it would be nice if there was a consistent strategy among them, but we work on what we have time to accomplish. My general guidance to teams that I work with is to pick an ORM only if it makes sense for the project and to put abstractions in place to make it convenient to use. Generally I prefer NHibernate (I have more experience with it) but there are many good solutions available
2. Yes, I have worked on at least two projects where we were brought in with the sole-purpose of removing existing third-party components (including ORM frameworks) and replacing them with other components. In one case we were moving from a home-built ORM to NHibernate, and in the other we were moving from a third party ORM to one the customer asked us to design for them. Both projects were complex and involved lots of changes which the application(s) did not handle gracefully. Some of this (not all) can be attributed to the fact that the code was closely coupled with its data storage strategy.