Я знаю, что модели домена и карты данных являются выбором ООП-сноба (используя «сноб» дополнительным образом, как Мартин Фаулер называет себя), однако даже Фаулер говорит в POEAA, что
«Active Record – хороший выбор для логики домена, которая не слишком сложна …»
У меня есть простая модель продукта и счета-фактуры, а не слишком много таблиц / объектов / концепций для модели, а отношения не слишком сложны. Итак, это хороший вариант использования Active Record?
Фаулер также утверждает, что активная запись похожа на шлюз данных строк, разница заключается в том, что Active Record имеет логику домена.
Предполагая, что это действительный прецедент для Active Record, и поскольку Zend предоставляет Row Data Gateway, решение интеллектуального (в отличие от простого добавления имени таблицы), расширяющего эти объекты, кажется хорошим способом создания объектов Active Record с использованием Zend Framework , Действительно, эта концепция обсуждается в этом SO-ответе . Является ли это приемлемым способом реализации Active Record внутри Zend Framework?
Конечно, наиболее популярным ответом на этот вопрос является вопрос Билла Карвина (который работал над реализацией Zend Db), рекомендуя не использовать Zend_Db_Table или Zend_Db_Row таким образом (по крайней мере, так я его читал).
Я полностью согласен с желанием перейти к решению Data Mapper, если рассматриваемая модель домена становится более сложной. Я смотрел на различные ORM / DataMappers (не только для модели домена, о которой идет речь, в последнее время больше читают о шаблонах проектирования ООП), и они действительно кажутся слишком важными для некоторых вещей.
Я сделал это и был полностью доволен результатом.
IMO, единственное, что вы никогда не должны делать, это использовать родительские методы в контроллерах и представлениях / видах справки. т.е. всегда пишите свои собственные методы в расширенных классах Zend_Db_Table_Abstract и Zend_Db_Table_Abstract_Row, которые используются остальной частью вашего приложения. Это оставит вам возможность поменять ваш TDG / AR на что-то более сложное, если возникнет такая необходимость.
Для чего-то простого, тогда да, модели, расширяющие пакет Zend_Db_Table, – прекрасный выбор. Я использовал его много раз с большим успехом, и он выглядит примерно так:
class App_Model_Users extends Mojito_Model_Abstract { protected $_dbTableClass='App_Model_Users_Table'; public function getByEmail($email) { $Select=$this->_DbTable->select()->where(new Zend_Db_Expr('LOWER(usrEmail)=?'),strtolower($email)); $User=$this->_DbTable->fetchRow($Select); return $this->verifyRow($User); } } class App_Model_Users_Table extends Zend_Db_Table_Abstract { protected $_name = 'users'; protected $_primary = 'user_id'; protected $_rowsetClass = 'App_Model_Users_Rowset'; protected $_rowClass = 'App_Model_Users_Row'; } class App_Model_Users_Rowset extends Zend_Db_Table_Rowset_Abstract { } class App_Model_Users_Row extends Zend_Db_Table_Row_Abstract { protected function _insert() { // pre instert logic such as: $this->password = sha1($this->password); } protected function _postInsert() { // email user a welcome } protected function _postDelete() { // delete related files such as avatar // can also get a rowset of related many's to delete } }
Вы можете прочитать больше здесь http://talentedmrjones.posterous.com/simple-models-with-zenddbtable
Конечно, вам может не понадобиться или нужна вся функциональность, которую я распространяю от Mojito_Model_Abstract, но я уверен, что вы получаете суть происходящего.