Isn't what you're describing essentially the ActiveRecord pattern? An object that has the internal capabilities to perform the various CRUD operations direct to a persistence store and only operates on itself?
EDIT: Also, from an architectural standpoint, do you not think that having SQL-speaking objects written in this fashion is too tightly coupled? What do you think of a "Clean Architecture" implementation with respect to your idea?
That's the point I'm trying to explain in the article. The idea of an "object" in OOP is to be a self-sufficient entity, capable of doing ALL operations internally. When I'm doing dao.insert(bean) - I let some DAO to extract my data and use them somehow. It's a violation of the basic principle of OOP - encapsulation.
Understood. I agree that some popular ORM tools are a mess and generally fail in delivering on what they "promise".
I also agree that having some objects speak SQL is a cleaner alternative (whether using a bridge as in your article, or otherwise).
However, I don't agree that OOP requires that every object encapsulate ALL operations. Specifically, I don't think embedding SQL operations directly in these objects is optimal, as it too tightly couples the object with the underlying persistence mechanism. And, it puts too much responsibility on the class.
Following your approach of doing ALL operations internally for the sake of encapsulation, it seems that you'd also have the object be responsible for, say, rendering itself in the view and a whole host of other responsibilities which could result in huge, monolithic objects that are difficult to maintain.
EDIT: Also, from an architectural standpoint, do you not think that having SQL-speaking objects written in this fashion is too tightly coupled? What do you think of a "Clean Architecture" implementation with respect to your idea?