This post originated from an RSS feed registered with Ruby Buzz by David Heinemeier Hansson. Original Post: Active Record vs Data Mapper in Rails Feed Title: Loud Thinking Feed URL: http://feeds.feedburner.com/LoudThinking Feed Description: All about the full-stack, web-framework Rails for Ruby and on putting it to good effect with Basecamp Latest Ruby Buzz Posts Latest Ruby Buzz Posts by David Heinemeier Hansson Latest Posts From Loud Thinking

Florian writes after reading about how the Active Record implementation in Rails works:

i dont see how active record is not marrying your bussiness objects with the orm solution. quite frankly i think its even worse with active record, because you marry each indidual business object to active record, since each one inherits from ActiveRecord::Base.

Perhaps I wasn't clear. I willingly pay the price of marrying my business objects to the ActiveRecord::Base to get a much more natural API in return. No, I can't swap persistance implementations. That's the cost.

In my opinion, however, that's a much smaller price than most people think. I'm not trying to create business objects that can be used in with other persistance methods or otherwise be reused out of the Active Record context.

I am much more interested in decreasing the amount of effort it takes to build a database-backed domain model. ActiveRecords are much simpler, and hence much faster, to both develop and use than data mapper approaches.

This is one of the original advantages of the Active Record pattern as described by Martin Fowler.

Now what my ActiveRecord implementation does is to enlarge the applicability of the original pattern by simulating traditional OO techniques, such as collections and inheritance, with constructs that are compatible with relational databases.

No, you don't get the full offer of opportunities that straight OO with a data mapper holds. I'd like to think, though, that Active Record gives you 80% of the features for 20% of the effort.