Think: what are the main concerns of an O/RM? You must have thought about performance and productivity. Think again. You probably want a “headacheless” technology to share great part of your work hours in the next months of your current project, don’t you?
If the answer is yes start chasing Persistence Ignorance. Do it tirelessly because it worth. Now why am I saying that?
Fortunately nowadays communities and development teams have started to care about software design and business abstraction. It means that in most of LoB applications data persistence have become a secondary concern. People no longer write tons of code because they have a database set up, but they need to persist data after writing and designing tons of business code.
This inversion of values is possible thanks (not only) to Persistence Ignorance. DOT.
If your O/RM choice was designed considering PI, you can test-drive your design cranking all the business code you want without – most important of all – spending too much time mapping your entities.
Even the decent O/RM cannot be 100% transparent to our entities. There is no pure-POCO objects that “completely ignore” the object-relational mapping.
The key here is to pick the technology that is most unobtrusive to your business code. We shall not become slaves of mapping technologies unless it’s a primary requirement.
Life's too short for bad software 