php - ¿Puede un modelo simple simplemente extender Zend_Db_Row(esencialmente Active Record)?

oop zend-framework

Question

Sé que los Modelos de Dominio y los Data Mappers son la elección del snob OOP (usando ''snob'' de forma complementaria, como Martin Fowler se llama a sí mismo); sin embargo, incluso Fowler dice en POEAA que

"Active Record es una buena opción para la lógica de dominio que no es demasiado compleja ..."

Tengo un producto simple y un modelo de dominio de factura, no demasiadas tablas / objetos / conceptos para modelar, y las relaciones no son demasiado complejas. Entonces, ¿ es este un buen caso de uso para Active Record?

Fowler también afirma que Active Record es similar al Row Data Gateway, con la diferencia de que Active Record tiene lógica de dominio.

Asumiendo que este es un caso de uso válido para Active Record, y dado que Zend proporciona Row Data Gateway, una solución de inteligencia (en lugar de simplemente agregar el nombre de la tabla) extender esos objetos parece una buena manera de crear objetos Active Record usando Zend Framework . De hecho, ese concepto se discute en esta respuesta SO . ¿Es esta una forma aceptable de implementar Active Record dentro del Zend Framework?

Por supuesto, la respuesta más popular a esa pregunta es una por Bill Karwin (que trabajó en la implementación Zend''s Db), recomendando no usar Zend_Db_Table o Zend_Db_Row esta manera (al menos así es como lo leí).

Acepto totalmente el deseo de pasar a una solución de Data Mapper si el modelo de dominio en cuestión se vuelve más complejo. He visto varios ORM / DataMappers (para más que solo el modelo de dominio en cuestión, he estado leyendo más sobre los patrones de diseño de OOP últimamente), y realmente parecen demasiado para algunas cosas.

Answer 1

Lo hice y estoy completamente satisfecho con el resultado.

IMO, lo único que nunca debes hacer es usar los métodos principales en tus controladores y vistas / ver ayudantes. es decir, siempre escriba sus propios métodos en las clases extendidas Zend_Db_Table_Abstract y Zend_Db_Table_Abstract_Row que utiliza el resto de su aplicación. Esto le dejará la opción de cambiar su TDG / AR por algo más complejo si surge la necesidad.

Answer 2

Para algo simple, entonces sí, los modelos que extienden el paquete Zend_Db_Table son una buena elección. Lo he usado muchas veces con gran éxito, y se ve así:

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
    }

}

Puedes leer más aquí http://talentedmrjones.posterous.com/simple-models-with-zenddbtable

Por supuesto, es posible que no necesites o quieras todas las funcionalidades que extiendo de Mojito_Model_Abstract, pero estoy seguro de que entiendes lo que está sucediendo.