Data Mapper и Zend Framework - PullRequest
Новая
       21

Data Mapper и Zend Framework

3 голосов
/ 01 октября 2011

Я реализую шаблон проектирования Data Mapper в своем веб-приложении Zend Framework, и все идет хорошо, мне очень нравится работать с картографом данных в Zend, а не применять только шаблон Row Gateway, но у меня возникла проблема, связанная смоя архитектураЯ не уверен, как ссылаться на ограничения внешнего ключа и работать с ними в режиме ООП с помощью моего средства отображения данных.Итак, у меня есть класс Model, класс DbTable и класс Mapper.Должен ли я поместить все отношения внешних ключей в мой класс DbTable, и таким образом я могу получить в своем преобразователе, используя функцию findDependentRowset(), или лучшим подходом было бы создать экземпляр зависимого класса в моем преобразователе.Какова наилучшая практика ООП при сопоставлении внешних ключей с использованием шаблона Data Mapper?

Ответы [ 2 ]

4 голосов
/ 01 октября 2011

Я бы выбрал DataMapper, так как два других не должны знать идентификатор как таковой, хотя он всегда необходим для вызывающих отношений. 

Model
- Property accessors and private property data holders
- Functions regarding correct usage of model
- Relatioship callers (calls relationship fetches in the DbTable to get parents or children rows)or returns cached data

DbTable
- Provides all static functions used to query data and instanciate the related Models such as :getById, getByName, getByComplexSearch, etc
- Provides all static relationship loaders such as: getParents, getChildrens and any other version you need

DataMapper
- Does the real meat and provides the getObjects method which accepts either a query part or a full query and loads the data into the ModelObjects and reads it back into a update, insert, delete query when needed
- Datamapper should be in charge of checking for relationship faults when inserting, updating or deleting using transactions if in InnoDB.

Имеет ли это какой-то смысл?

2 голосов
/ 30 октября 2011

Раньше у меня было findDependentRowset в моих системах.Но не больше!В большинстве случаев это пустая трата ресурсов.Объединения таблиц должны быть в вашем операторе SQL.

См. Мой ответ здесь: Сделанные вручную запросы против findDependentRowset

Я все еще далек от использования Doctrine илиPropel (мне это никогда не было нужно).Может быть, когда-нибудь. (сейчас используется Доктрина 2 . Итак ... Я предлагаю вам то же самое сейчас)

СТАРЫЙ ОТВЕТ

После нескольких лет работы с Zend Framework я столкнулся со следующей архитектурой:

1) У меня есть абстрактный маппер, который расширяет все мои мапперы: Zf_Model_DbTable_Mapper

2) У меня также есть абстрактная модель (объект домена), похожая на шлюз данных строк, за исключением того, что он не является шлюзом.Это универсальный объект домена: Zf_Model

3) При заполнении графов объектов (SQL-соединения) один маппер делегирует другим мапперам, которые отвечают за данный объект.

Пример

Этот метод взят из абстрактного картографа: 

    public function getById($id) 
    {


        $tableGateway = $this->getTable();

        $row = $tableGateway->fetchRow('id =' . (int) $id);

        if (!$row) 
            retur null;

        $row = $row->toArray();

        $objectName = $this->getDomainObjectName();
        $object = new $objectName($row['id']);
        $object->populate($row);

        return $object;    
    }
...