Zend framework – Почему я должен использовать data mapper / Db_Table_Row?

Расширенный вопрос: Почему я должен использовать data mapper / Db_Table_Row, где DbTable способен обрабатывать большинство основных задач для обработки данных.

В настоящее время я изучаю ZF v1.11

Для манипуляции с базами данных я создал DbTable для каждой таблицы. Например, таблица «users» представлена ​​Application_Model_DbTable_Users без дополнительных кодов.

При манипулировании данными я могу использовать:

<?php $uTable = new Application_Model_DbTable_Users(); $newUid = $uTable->insert(array('name'=>'Old Name', 'email'=>'')); $user = $uTable->find($newUid)->current(); // Then I can use $user which is instance of Table_Row $user->name = "New Name"; $user->email = "email@addr.com"; $user->save(); 

Мой вопрос: когда мне нужно определить класс строк (предполагается, что Table_Row упоминается как DataMapper в ZF-Tutorials)

 // By, adding this to the DbTable class protected $_rowClass = 'Application_Model_User'; 

Каковы преимущества наличия класса Row для каждого объекта? Может ли кто-нибудь указать мне на лучшие практики для этого.

Related of "Zend framework – Почему я должен использовать data mapper / Db_Table_Row?"

Вам не нужно определять собственный Table_Row. Однако это может быть полезно во многих случаях, особенно если вы хотите определить некоторые конкретные методы или свойства для данной строки пользователя. Они также могут улучшить читаемость вашего кода.

Например, в случае таблицы «Пользователи» вы можете определить метод с именем getFullName () в пользовательской строке пользователя как:

 public function getFullName() { return $this->firstName . ' ' . $this->lastName; } 

Затем, когда вы получаете объект строки пользователя, чтобы получить полное имя пользователя, вы просто выполните:

 $user = $uTable->find($newUid)->current(); $fullName = $user->getFullName(); 

Второй пример – когда у вас есть таблица родительских таблиц, например Адреса. В этом случае вы можете определить метод getAddress в строке пользователя:

 public function getAddress() { return $this->findParentRow('Application_Model_DbTable_Addresses'); } 

В этом случае вы получите объект Address row для текущего пользователя следующим образом:

 $user = $uTable->find($newUid)->current(); $addressRow = $user->getAddress(); 

Другим примером может быть создание пользовательских методов delete или instert. Предположим, вы хотите, чтобы вы не хотели удалять пользователя admin с помощью метода delete (). Затем вы можете перегрузить метод удаления из Zend_Db_Table_Row следующим образом:

 public function delete() { if ('admin' === $this->userRole) { return 0; } return parent::delete(); } 

Таким образом, вы не сможете удалить пользователя администратора, просто вызвав delete () для объекта строки пользователя:

  $user = $uTable->find($newUid)->current(); $rowsDeleted = $user->delete(); // would be 0 if $user is admin 

Это всего лишь три основных примера, показывающих полезность определения ваших собственных классов строк. Но, конечно, они не нужны. Однако, по собственному опыту, они весьма удобны.

В двух словах: речь идет об изоляции.

Zend_Db_Table – это реализация шлюза данных данных. Он передает CRUD доступ к определенному представлению таблицы через один класс. Он обычно используется с табличным модулем , например классом, который содержит бизнес-логику для записей, обрабатываемых шлюзом.

Zend_Db_Table_Row – это реализация шаблона шлюза данных строк . Здесь возвращаемые объекты выглядят точно так же, как и запись в базе данных, и они содержат бизнес-логику для работы с этими данными, но они не содержат логику для CRUD с таблицей, из которой они были (это будет ActiveRecord), но агрегируют их.

Строковые шлюзы данных являются точными, если у вас нет слишком большого несоответствия реляционного импеданса объекта . Как объект сохраняется в реляционной базе данных и как он должен выглядеть в объектном мире, часто бывают разные вещи. При использовании модели домена ваши бизнес-объекты обычно структурируются по-другому, чем они хранятся в базе данных. Таким образом, вы не можете легко CRUD их из базы данных. Здесь DataMapper вступает в игру.

DataMapper берет на себя ответственность за сопоставление объектов домена с наборами записей и наоборот. Это упрощает ваше приложение, поскольку оно отделяет объекты домена от структуры базы данных. Он сохраняет их разделенными и дает вам больше гибкости в том, как моделировать оба уровня (постоянство и домен).