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.
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.