For the ActiveRecord

True to the mantra of Rails, ActiveRecord makes persistence staggering simple. I still raise an eyebrow to persistence being this simple:

class User < ActiveRecord::Base
end

Yep, that’s all that’s needed to map to a table named users. ActiveRecord instantly generates a heap of methods and a few fields in the class facilitating CRUD operations with the table.

While I’ll defer from presenting the essentials of ActiveRecord (there’s plenty of material out there) here’s a teaser; fields will be automatically generated in the class representing each of the tables columns and methods like find_by_name_and_role (aka instant finders) will also be added, presenting queries in DSL form.

While simplicity is beauty, Java developers cringe at the prospect of using an Active Record approach to persistence, mixing the concerns of persistence with the domain model. Their accustomed to the Data Mapper approach employed by prominent Java ORM tools. Their mantra is all about a clean separation of layers to facilitate testability, maintainability, comprehension and to a lesser degree task separation. From their point of view, if you use that User object in a context where persistence is not needed you’ve got that extra persistence baggage hanging around.

Java developers sink deeper into their seats when they learn how prominent class methods (aka static methods) are in ActiveRecord. Out the window go pluggability and testability in comes a tight domain language (not so bad) and so called ‘unit tests’ that integrate with the database (not so good).

So me being one of those Java developers passionate about clean layer separations and anal enough to blast colleagues for incorrect use of the term ‘unit test’ – sure, I’ve shaken my head and cringed a tad. But for pure simplicity, hats off to the ActiveRecord team.

I guess it’s a contrast in two style of elegance; simplicity vs. conventional OO design. It’s interesting to note that latter is often considered an art taking years to grasp, while the former perhaps requires much less of a mental investment. But in saying that, part of the simplicity of ActiveRecord and Rails is that some of the OO design decisions are made for you. The layers are already clearly defined (although the persistence and domain layers are blurred), the tools already chosen.

But shifting the focus back to ActiveRecord, do I really care about that blurring if persistence of my domain model is a key concern of my application? Heck no. I can still test my domain logic without persisting a thing. I don’t have to configure a mapping layer, I just stick to ActiveRecord’s numerous naming conventions and it does that for me. The benefits outweigh the merit of conventional OO wisdom.

While I’ve been learning the finer details of ActiveRecord and appreciating its simplicity, I’ve been occasionally confused by a feature or design decision made by the ActiveRecord team. Top of the pops are the features added to classes involved in one-to-one, one-to-many and many-to-many associations.

So in my next few blogs I’ll demonstrate these features through tests, something that would have been a handy accompaniment to the explanations of these associations in Agile Web Development with Rails.

Note: For those after a detailed comparison of ActiveRecord and Hibernate, the Hibernate vs. Rails Showdown posted almost a year ago on TheServerSide quickly sketches out the differences.