Because of the ubiquity of the Ruby on Rails web framework, the Rails ActiveRecord library has become the de-facto standard for managing database persistence in Ruby applications. But ActiveRecord—both the library and the pattern it embodies—is not a one-size-fits-all solution. When Martin Fowler first defined the Active Record pattern, he noted that it only works well:
” …if the Active Record objects correspond directly to the database tables… if your business logic is complex, you’ll soon want to use your objects direct relationships, collections, inheritance, and so forth. These don’t map easily to Active Record, and adding them piecemeal gets very messy.“
Most Ruby developers I know have a story or two about business logic in Active Record objects getting very messy indeed. But what is the alternative?
The ROM library is one option. This library seeks to cleanly separate various aspects of database persistence into small, focused objects. Today, guest chef Tim Riley joins us for the first in a three-part exploration of ROM. In today’s episode, you’ll get a first look at what makes ROM’s approach unique. Enjoy!