Design patterns 数据映射器/域驱动设计的PoEEA逻辑

我对DataMapper模式的逻辑有点困惑

到目前为止我所掌握的（伪代码，这里不寻找特定语言的答案）：

问题：多个数据映射器的用途是什么

---

我的意思是，考虑到数据映射器除了遵循实现规则之外，不应该关心模型或dao，为什么我会有一个HouseDataMapper和一个CardDataMapper。我唯一的想法是为不同的模型和数据访问对象提供不同抽象（规则）的不同数据映射器。我这样问是因为我看到的大多数示例都将HouseDataMapper和CardDatamapper视为独立的实体，这不会破坏DataMapper PoEEA的用途吗？

进一步阅读，我发现了我的错误：

“数据映射器是将内存中的对象与数据库分离的软件层。它的职责是在两者之间传输数据，并将它们彼此隔离。”-

---

因此，在我困惑的地方，数据映射器（混凝土）应该知道内存中的对象（实例化的模型对象），它只是将它们与数据库（数据访问对象）隔离开来。

进一步阅读，我发现了我的错误：

“数据映射器是将内存中的对象与数据库分离的软件层。它的职责是在两者之间传输数据，并将它们彼此隔离。”-

因此，在我困惑的地方，数据映射器（具体）应该知道内存中的对象（实例化的模型对象），它只是将它们与数据库（数据访问对象）隔离开来

class Car implements DomainObjectAbstract {
    ... properties ...
    ... accessors / mutators ...
    ... behaviors ... // drive, park, whatever.
}

class House implements DomainObjectAbstract {
    ... properties ...
    ... accessors / mutators ...
    // may not have behaviors, a house doesn't 'do anything, it just is'
}

class DaoCar implements DaoAbstract {
    // some code to handle reading and writing car object to database table
}

class DaoHouse implements DaoAbstract {
    // some code to handle reading and/or writing house object to an xml file
}

class DataMapper {
    protected _dao;
    protected _model;

    function getDao() return this->_dao;
    function setDao( DomainObjectAbstract dao) this->_dao = dao;
    function getModel() return this->_model;
    function setModel( DaoAbstract model ) this->_model = model;

    function create() { // create a new instance of the model }
    function save() { // create or update the model into persistent storage }
    function fetch( id ) { // fetch record from storage and return a property populated model }
    ... etc ...
}