Introduction » Why ROM?
Many Rubyists start their journey being exposed to Rails and its favored object
relational mapping (ORM) library,
Active Record is an
implementation of the Active Record pattern. In this pattern, objects carry
the data and the behavior that operates on that data.
Active Record pattern has been widely adopted by the Ruby community,
mostly due to the success of Rails; however, it's a pattern with well known
shortcomings. In complex applications,
Active Record is no longer a good
choice as it tightly couples your application's domain layer with the underlying
database. It's especially problematic in Rails - where its
provides a gigantic interface to handle many different concerns. As a result,
many Rails applications suffer from rapidly increasing complexity, caused by
internal coupling and lack of a clean domain layer, to a point where
maintaining and growing an application becomes very difficult.
The benefit of using
Active Record, which speeds up initial development and
lowers the costs during early stages of a project, quickly becomes irrelevant
once complexity of the application grows and adding new features and fixing bugs
takes more time than it should.
ROM provides an alternative way of handling persistence and related concerns. It can be used as effectively, in terms of fast development, as Active Record, with the great benefit of being able to adjust your design to the growing complexity of your application. Loose coupling between your application's domain layer and the underlying databases simplifies your code and the persistence layer, handled by ROM components, gives you powerful interfaces to help deal with complexity and performance issues.
When using ROM you are not limited to any ORM abstraction, because ROM doesn't have it. Instead, you can leverage features of your database using adapter interfaces, which can also help you to reduce the complexity of your application.
ROM focuses on simplicity and removes unnecessary abstractions. It helps you in working efficiently with the data and turning it into meaningful information.
The single biggest reason to use ROM is to have the freedom to design the domain layer however you like - you aren't tied to the structure of your database. This flexibility is of primary concern to ROM.
ROM makes it easy to work with, and switch between, different data sources. A
minimum structure is provided with more adapters being created every day. The
rom-sql, is built on
which is stable and brings with it immediate support for many different types
Each piece of ROM is small and understandable making it easier to find what you need when adding the library to your project.
ROM favors explicitness and avoiding "magic" as much as possible.
ROM components are small, simple to use and allows powerful composition. Higher-level abstractions can be easily built on top of lower-level components.
ROM is fast, and it gives you the power to improve performance easily when default behavior doesn't satisfy you. No magic, no leaky abstractions, you're in control.