ActiveRecord Is Even Worse Than ORM

You probably remember what I think about ORM, a very popular design pattern. In a nutshell, it encourages us to turn objects into DTOs, which are anemic, passive, and not objects at all. The consequences are usually dramatic—the entire programming paradigm shifts from object-oriented to procedural. I’ve tried to explain this at a JPoint and JEEConf this year. After each talk, a few people told me that what I’m suggesting is called ActiveRecord or Repository patterns.

Moreover, they claimed that ActiveRecord actually solves the problem I’ve found in ORM. They said I should explain in my talks that what I’m offering (SQL-speaking objects) already exists and has a name: ActiveRecord.

I disagree. Moreover, I think that ActiveRecord is even worse than ORM.

ORM consists of two parts: the session and DTOs, also known as “entities.” The entities have no functionality; they are just primitive containers for the data transferred from and to the session. And that is what the problem is—objects don’t encapsulate but rather expose data. To understand why this is wrong and why it’s against the object paradigm, you can read here, here, here, here, and here. Now, let’s just agree that it’s very wrong and move on.

What solution is ActiveRecord proposing? How is it solving the problem? It moves the engine into the parent class, which all our entities inherit from. This is how we were supposed to save our entity to the database in the ORM scenario (pseudo-code):

book.setTitle("Java in a Nutshell");
session.update(book);

And this is what we do with an ActiveRecord:

book.setTitle("Java in a Nutshell");
book.update();

The method update() is defined in book’s parent class and uses book as a data container. When called, it fetches data from the container (the book) and updates the database. How is it different than ORM? There is absolutely no difference. The book is still a container that knows nothing about SQL and any persistence mechanisms.

What’s even worse in ActiveRecord, compared to ORM, is that it hides the fact that objects are data containers. A book, in the second snippet, pretends to be a proper object, while in reality it’s just a dumb data bag.

I believe this is what misguided those who were saying that my SQL-speaking objects concept is exactly the same as the ActiveRecord design pattern (or Repository, which is almost exactly the same).

No, it’s not.