Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

ActiveRecord Is Even Worse Than ORM

DZone's Guide to

ActiveRecord Is Even Worse Than ORM

What's even worse in ActiveRecord, compared to ORM, is that it hides the fact that objects are data containers.

· Java Zone
Free Resource

Learn how to troubleshoot and diagnose some of the most common performance issues in Java today. Brought to you in partnership with AppDynamics.

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 read 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 from 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 misled 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.

Understand the needs and benefits around implementing the right monitoring solution for a growing containerized market. Brought to you in partnership with AppDynamics.

Topics:
activerecord ,orm

Published at DZone with permission of Yegor Bugayenko, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}