ORM Is an Offensive Anti-Pattern | Hacker News Reader

ORM Is an Offensive Anti-Pattern

yegor256.com

8 pointsyegor256a4 comments

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?

I agree. Question for you: In the comments section of your post, someone mentions another ORM. You responded, as follows:

>dao.insert(testBean);

>DB manipulations are outside of the "bean". That's wrong.

Why do you say this?

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.

Reply on news.ycombinator.com