Okay, here's a situation I've run into: I want to create a web frontend to an existing library. Naturally, the existing library already has some nice model-li

Okay, here's a situation I've run into: I want to create a web frontend to an existing library. Naturally, the existing library already has some nice model-like classes that I'll be working with. What I'd like to do is take those model-like classes and persist them to the database. It should just be a simple matter of mapping a few instance variables / attributes to database columns right? Well, it turns out this is fairly difficult with ActiveRecord. Firstly, ActiveRecord wants all your models to extend ActiveRecord::Base. But, I already have an existing class and the chances are I don't want to, or can't, change the existing class to extend AR::Base. So maybe I'll to create an ActiveRecord model that will wrap and delegate to the existing class. Ah, but AR::Base has a huge footprint and uses so much magic that it's downright painful to do delegation. You can't safely use method_missing because AR::Base does, and you're almost guaranteed to have a conflict where AR::Base and your existing class define the same methods anyway. Here's how DataMapper is different: You're not required to extend any sort of base class. Instead, you mixin a module with a tiny footprint. So, in your web frontend, you can open the existing model-like class, mixin DataMapper::Resource, and map your properties to columns. Because the footprint for DataMapper::Resource is so light, and it doesn't use any magic, it's unlikely we'll break the existing class. Even if we do break it with this approach, we're far more likely to succeed with delegation that we are under ActiveRecord. So, to bring it back to Merb and Rails, here's the key difference: ActiveRecord might be just fine for most projects. But, maybe DataMapper is sometimes better. Or, maybe another ORM is. In any case, Merb will let me work with whatever library I think is best for my project. Rails give you no choice. You either take the whole stack as is or you don't. And, that doesn't just apply to the ORM layer. The same can be said for template engines and javascript libraries.