zend tutorial mac how framework espaƱol composer php model-view-controller zend-framework model

php - tutorial - Modelos en el Zend Framework



zend framework download (11)

He estado investigando sobre Modelos para ZF y encontré una interesante serie de artículos de Matthew Weier O''Phinney que vale la pena consultar:

No es un "código de producción" y se deja mucho a la imaginación, pero es una buena lectura y me ha ayudado bastante.

¿Cuáles son algunas de las formas en que ha implementado modelos en Zend Framework?

He visto que el class User extends Zend_Db_Table_Abstract básica class User extends Zend_Db_Table_Abstract y luego realiza llamadas a eso en sus controladores:

$foo = new User;

$foo->fetchAll()

pero ¿qué pasa con los usos más sofisticados? La sección de inicio rápido de la documentación ofrece un ejemplo, pero todavía siento que no estoy obteniendo un ejemplo de "mejor uso" para los modelos en Zend Framework. ¿Alguna implementación interesante por ahí?

EDITAR: Debería aclarar (en respuesta al comentario de CMS) ... Sé hacer selecciones más complicadas. Me interesaron los enfoques generales del concepto de Modelo y ejemplos concretos de cómo otros los han implementado (básicamente, las cosas que el manual deja de lado y las cosas que hacen falta sobre cómo hacerlo).


Nunca use Zend_Db_Table como su modelo. Simplemente te mete en problemas. O bien escribe sus propias clases de modelo que usan Zend_Db_Table para hablar con su base de datos o puede leer la publicación de mi blog here para obtener un truco que le permite combinar en cierto modo la clase "Modelo" y Zend_Db_Table.

Lo principal es que cuando se usa Zend_Db_Table directamente en los controladores, se terminan haciendo las mismas cosas en varios lugares. Si tiene que cambiar algo de esa lógica, debe hacer un cambio en varios lugares. No está bien. Mi primer proyecto profesional fue hecho así porque yo era el único en la compañía que tenía que aprender a usar ZF y ahora es un desastre total.

También tiendo a escribir funciones auxiliares en mis clases para búsquedas sofisticadas. Algo así como $ table-> doNameFetchAll () o $ table-> doOrderFetchAll ().


Omita ZF para la parte de modelos, hay soluciones mucho mejores. La "M" en el "MVC" de ZF está bastante ausente. Al leer sus documentos, realmente no mencionan los modelos, lo que es bueno, significa que puede usar prácticamente cualquier cosa que desee sin tener que escribir muchos códigos de adaptador.

Eche un vistazo a Doctrine for models en su lugar. Se está convirtiendo rápidamente en el ORM de facto para PHP.


Personalmente Zend_Db_Table_Abstract y Zend_Db_Table_Row_Abstract . La principal diferencia entre mi código y el tuyo es que trata explícitamente la subclase de Zend_Db_Table_Abstract como una "tabla" y Zend_Db_Table_Row_Abstract como "fila". Muy rara vez veo llamadas directas para seleccionar objetos, SQL o los métodos de base de datos de ZF incorporados en mis controladores. Intento ocultar la lógica de solicitar registros específicos a las llamadas por detrás de Zend_Db_Table_Abstract como tal:

class Users extends Zend_Db_Table_Abstract { protected $_name = ''users''; protected $_rowClass = ''User''; // <== THIS IS REALLY HELPFUL public function getById($id) { // RETURNS ONE INSTANCE OF ''User'' } public function getActiveUsers() { // RETURNS MULTIPLE ''User'' OBJECTS } } class User extends Zend_Db_Table_Row_Abstract { public function setPassword() { // SET THE PASSWORD FOR A SINGLE ROW } } /* CONTROLLER */ public function setPasswordAction() { /* GET YOUR PARAMS */ $users = new Users(); $user = $users->getById($id); $user->setPassword($password); $user->save(); }

Hay numerosas formas de abordar esto. No creo que este sea el único, pero trato de seguir la intención del diseño de la ZF. (Aquí hay más de mis pensamientos y enlaces sobre el tema .) Este enfoque tiene un poco de clase pesada, pero creo que mantiene a los controladores enfocados en manejar las entradas y coordinarse con la vista; dejando el modelo para hacer el trabajo específico de la aplicación.


Puede hacer consultas más complicadas, consulte la sección Uso avanzado en la página del manual Zend_Db_Table .

$select = $table->select(); $select->from($table, array(''COUNT(reported_by) as `count`'', ''reported_by'')) ->where(''bug_status = ?'', ''NEW'') ->group(''reported_by'');


Trabajé para Zend e hice bastante trabajo en el componente Zend_Db_Table.

Zend Framework no brinda mucha orientación sobre el concepto de un "Modelo" con respecto al patrón del Modelo de Dominio. No existe una clase base para un Modelo porque el Modelo encapsula una parte de la lógica empresarial específica de su aplicación. Escribí un blog sobre este tema con más detalle.

La persistencia de una base de datos debe ser un detalle de implementación interna de un Modelo. El Modelo generalmente usa una o más Tablas. Es un diseño común pero inadecuado orientado a objetos considerar un Modelo como una extensión de una Tabla. En otras palabras, deberíamos decir Modelo HAS-A Tabla - no Modelo IS-A Tabla.

Este es un ejemplo de IS-A:

class MyModel extends Zend_Db_Table_Abstract { }

Este es un ejemplo de HAS-A:

class MyModel // extends nothing { protected $some_table; }

En un modelo de dominio real, usaría $ some_table en los métodos de MyModel.

También puede leer la versión de Martin Fowler sobre el patrón de diseño del Modelo de Dominio y su descripción del antipatrón del Modelo de Dominio Anemic, que es la forma en que desafortunadamente muchos desarrolladores se acercan a la programación de OO.


Un modelo no tiene nada que ver con la base de datos . ¿Qué sucede si estoy obteniendo datos de una fuente RSS o un servicio SOAP o leyendo archivos de la FS?

Puse todo este tipo de cosas en los modelos. En ese caso, mi clase modelo podría no extender nada . Estoy a punto de escribir un modelo que usa métodos de otros modelos.


Una entidad de base de datos no es el único tipo de componente de modelo. Como tal, realmente no tiene sentido hablar de modelos (en plural): su aplicación tiene un modelo, que contiene una multitud de componentes. Algunos de estos componentes podrían ser gateways de tabla (y por lo tanto se extienden desde Zend_Db ), mientras que otros no lo harían.

Te recomiendo que te hagas con el libro Domain Driven Design de Eric Evans, que hace un excelente trabajo al explicar cómo construir un modelo de objetos.


Yo uso Propel 1.3 en lugar de Zend_Db_Table. Es complicado de configurar, pero increíble. Puede examinar su base de datos y generar automáticamente todos sus modelos. En realidad genera 2 niveles y 2 tipos de modelo.

Ejemplos para la tabla ''usuario'':

Nivel 1: BaseModel & BasePeer: estos se sobrescriben cada vez que regenera su ORM. es decir, BaseUser.php y BaseUserPeer.php

Nivel 2: StubModel y StubPeer: estos no se sobrescriben. Ellos son los que personalizas. es decir, User.php y UserPeer.php

Tipo 1: Modelo: para operaciones CRUD básicas, no consultas, es decir, User.php Tipo 2: Peer, para consultas. Estos son objetos estáticos. es decir, UserPeer.php

Entonces para crear un usuario:

$derek = new User(); $derek->setFirstName(''Derek''); $derek->save();

Para encontrar todos los dereks:

$c = new Criteria(); $c->add(UserPeer::FIRST_NAME, ''Derek''); $dereks = UserPeer::doSelect($c);


puede extender la clase Zend_Db_Table_Abstract y agregarle algunos métodos útiles. por ejemplo, puede agregar un método changePassword () a su clase de usuario y manipular sus datos. o puede cambiar el método __toString () predeterminado de su clase, por lo que tendrá un método __toString () personalizado que, digamos, devuelve toda la información de contacto del usuario (nombre, dirección, número de teléfono) en una cadena con formato correcto . en tu constructor puedes poblar tus datos en las propiedades de tu objeto. luego úselos como:

public function __toString() { $data = $this->_name . '', '' . $this->_adderss . '', call: '' . $this->_phone; return $data; }

su modelo extiende el Zend_Db_Table_Abstract solo para facilitar el proceso de acceso a sus datos, pero la funcionalidad que podría tener sobre esos datos depende de su creatividad y necesidad. Te recomiendo el libro "php | architect''s guide to programming with zend framework" de Cal Evans. el libro es muy informativo y fácil de leer. los capítulos 4 y 6 serán útiles para este asunto.