Object Relational Mappers, ORMs. The supposed cure to the supposed impedance mismatch between objects and relational tables.
Okay, alright.
First of all, there is no impedance mismatch, and the reason for that is that objects and relational tables aren't related at all. They're completely different things.
A relational database is a data model. It's a model of data structures.
An object model is a model of behavior, the behavior of collaborating objects.
The two are not related.
This is obvious when you look at how objects are structured.
Objects are bags of functions with, perhaps, private data. And by "perhaps" I mean that perhaps there's data in them and perhaps there isn't. You're not allowed to know.
Data structures, relational tables and things like that, are bags of data with no functions.
Notice how the two are the opposite of each other:
An object is a bag of functions with no obvious data. A data structure is a bunch of data with no obvious functions. They don't have anything to do with each other. So there is no impedance mismatch.
And an ORM is not an object relational mapper. An ORM is a data structure hydrator. All it really does is take the data from one place and move it to another. That's all.
Now there's nothing wrong with using an ORM (if you want to use one, that is fine). It will take the data out of the relational database and move it into a more convenient data structure that your business objects can then make use of.
However, and here is the big mistake that people make. Your business objects should not know about the ORM.
The ORM should hydrate data structures your business objects can know about those data structures.
And here's the fundamental rule. A fundamental rule. Low-level things, like ORMs, should depend on high-level things, like business objects.
You want all of your source code dependencies pointing towards the business objects.
You want a hard line with your business objects above the line and all of your data gunk (the ORM, and the SQL, and the database); you want that all below the line. And every source code dependency crossing that line points up towards the business object.
Last thought. In any architectural boundary (across any architectural boundary), the data structures live on the high-level side. I'll leave you to ponder that.