What, *specifically*, makes DataMapper more flexible than ActiveRecord?

I'm comparing Doctrine 2 and Propel 1.5/1.6, and I'm looking in to some of the patterns they use. Doctrine uses the DataMapper pattern, while Propel uses the ActiveRecord pattern. While I can see that DataMapper is considerably more complicated, I'd assume some design flexibility comes from this complication. S开发者_JAVA技巧o far, the only legitimate reason I've found to use DataMapper over ActiveRecord is that DataMapper is better in terms of the single responsibility principle -- because the database rows are not the actual objects being persisted, but with Propel that doesn't really concern me because it's generated code anyway.

So -- what makes DataMapper more flexible?

---

I've worked with both, new Propel and Doctrine2. What DataMapper (and I mean Doctrine2) makes adorable is that your domain objects are clean and simple, they don't extend irrelevant classes which add many irrelevant methods to your classes (violating SRP as you said). They're just simple entities with a few properties and a few methods that are a part of your business layer. And that, of course, lets you write unit tests for them and reuse them in the future.

I wouldn't say DataMapper considerably more complicated. It is complicated if you write your own implementation of DataMapper, but Doctrine2 is way easier to use than propel (maybe except for setting it up, we do that only once anyway). It has an entity manager that manipulates any entities. You may have entity repositories for complex queries. And that's it.

And an entity is as simple as:

/**
 * Question
 *
 * @Entity
 */
class Question
{
    /**
     * @Column(type="string")
     */
    private $title;

    public function getTitle() { return $this->title; }
    public function setTitle($title) { $this->title = $title; }

}

In Propel we would have 6 classes for that entity which would contain a lot of generated and often unused code.

What makes DataMapper more flexible? Simplicity that it provides.

---

ActiveRecord makes a data type do two things -- own responsibility for persisting data to a database, and own responsibility for storing the data for general calculations. This means that if you want to change the data store to which data is persisted in the future, code which generally doesn't have to care about database behavior is exposed to the change.

DataMapper completely decouples a given database implementation from a set of in-memory working objects, meaning the same internal working data type can be persisted to multiple databases, without modifying code that otherwise uses the working type.

For example, with DataMapper patterns, if tomorrow you want to add XML export for your data, you implement one new data mapper, the "MyDataToXmlDataMapper" or similar, that adds the new persistence format, and no other code has to change. With ActiveRecord adding such functionality requires changing the interface of the working data type.