Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. PHP
Code

Zend Framework desde cero - Modelos e Integración de Doctrina ORM

by
Difficulty:IntermediateLength:LongLanguages:

Spanish (Español) translation by Steven (you can also view the original English article)

¿Listo para llevar tus habilidades de PHP al siguiente nivel? En esta nueva serie "desde Cero", nos centraremos exclusivamente en Zend Framework, un framework PHP de pila completa creado por Zend Technologies. Este segundo tutorial de nuestra serie se titula "Modelos e Integración de Doctrine ORM".


Comentario

¡Bienvenido de nuevo a nuestra serie Zend Framework desde cero! En nuestro último tutorial, aprendimos algunas cosas básicas acerca de Zend Framework, tales como:

  • Dónde descargar los últimos archivos de Zend Framework
  • ¿Dónde y cómo configurarlo localmente?
  • Crear tu primer proyecto de Zend Framework y configurar un VirtualHost en tu servidor web
  • Cómo exactamente Zend Framework implementa el patrón MVC y su enrutamiento de aplicación predeterminado
  • Pasando datos desde un controlador a su vista
  • Creación del diseño de un sitio para su aplicación Zend Framework
  • Creando nuevos controladores y acciones.

Si aún no lo has hecho, deberías leer el tutorial anterior. Realmente te facilitará comprender algunos conceptos básicos de Zend Framework y te ayudará a comprender algunas de las cosas que discutimos en este tutorial.

En esta segunda parte de la serie, hablaremos de una parte crucial de cualquier aplicación web: los MODELOS. También veremos cómo integrar el muy popular ORD de Doctrine con nuestro proyecto Zend Framework, y descubriremos por qué es mucho mejor usarlo el Zend_Db nativo de Zend Framework. Así que, sin más preámbulos, ¡comencemos!


¿Qué son exactamente los "modelos"?

Cuando comencé a tratar de comprender el concepto de MVC, leí varias analogías, que intentaron explicar exactamente qué representa cada uno de estos componentes. Una de las mejores analogías que he leído hasta ahora fue la de este artículo, Otra forma de pensar acerca de MVC. Es algo parecido a esto:

Imaginemos un banco.

La caja de seguridad es la base de datos: aquí es donde se almacenan todos los bienes más importantes y están bien protegidos del mundo exterior.

Luego tenemos a los banqueros o en términos de programación, los Modelos. Los banqueros son los únicos que tienen acceso a la caja fuerte (DB). Generalmente son gordos, viejos y perezosos, que siguen bastante bien con una de las reglas de MVC: *Modelos gordos, controladores flacos*. Veremos por qué y cómo. Esta analogía se aplica un poco más tarde.
Ahora tenemos nuestros trabajadores bancarios promedio, los geófilos, los corredores, los controladores. Los controladores o gofers hacen todo el recorrido, por eso tienen que estar en forma y ser delgados. Toman el botín o la información de los banqueros (los Modelos) y la llevan a los clientes del Banco las Vistas.

Los banqueros (modelos) han estado en el trabajo por un tiempo, por lo tanto, toman todas las decisiones importantes. Lo que nos lleva a otra regla: *mantener la mayor lógica de negocios en el Modelo como sea posible*. Los controladores, nuestros trabajadores promedio, no deben tomar tales decisiones, le piden detalles al banquero, obtienen la información y se la transmiten al cliente (la Vista). Por lo tanto, continuamos siguiendo la regla de los *modelos gordos, controladores flacos*. Los gophers no toman decisiones importantes, pero no pueden ser simples tontos (por lo tanto, un poco de lógica de negocios en el controlador está bien). Sin embargo, tan pronto como el Gopher comienza a pensar demasiado, el banquero se enoja y su banco (o su aplicación) se cierra. Así que, una vez más, siempre recuerda descargar tanta lógica de negocios (o toma de decisiones) al modelo.

Ahora, los banqueros no van a hablar directamente con los clientes (la Vista), son demasiado importantes en sus cómodos sillones para eso. Por lo tanto, se sigue otra regla: Los modelos no deben hablar con vistas*. Esta comunicación entre el banquero y el cliente (el Modelo y la Vista) siempre es manejada por el Gopher (el Controlador). (Sí, hay alguna excepción a esta regla para los clientes súper VIP, pero sigamos con lo básico por el momento).

También sucede que un solo trabajador (Controlador) tiene que obtener información de más de un banquero, y eso es perfectamente aceptable. Sin embargo, si los banqueros están relacionados (de lo contrario, ¿de qué otra manera obtendrían tan buenos trabajos?)... los banqueros (Modelos) se comunicarán entre sí primero, y luego pasarán la información acumulada a su Gopher, quien con gusto la entregará al cliente ( Ver). Así que aquí hay otra regla: *Los Modelos relacionados proporcionan información al controlador a través de su asociación (relación)*.

Entonces, ¿qué pasa con nuestro cliente (la vista)? Bueno, los bancos cometen errores y el cliente debe ser lo suficientemente inteligente como para equilibrar su propia cuenta y tomar algunas decisiones. En términos de MVC obtenemos otra regla simple: *es bastante correcto que las vistas contengan cierta lógica, que trata con la vista o presentación*. Siguiendo nuestra analogía, el cliente se asegurará de no olvidar usar pantalones mientras van al banco, pero no les dirán a los banqueros cómo procesar las transacciones.

En una palabra:

  • Los modelos son representantes de la base de datos y deben estar donde reside toda la lógica empresarial de una aplicación
  • Los controladores se comunican con los modelos y les piden que recuperen la información que necesitan
  • Esta información es luego pasada por un Controlador a la Vista y es renderizada
  • Es muy raro que un modelo interactúe directamente con una vista, pero a veces puede suceder cuando sea necesario.
  • Los modelos pueden hablar con otros modelos y no son independientes. Tienen relaciones que se entrelazan entre sí.
  • Estas relaciones hacen que sea más fácil y rápido para un Controlador obtener información, ya que no tiene que interactuar con diferentes Modelos; los Modelos pueden hacerlo ellos mismos

Podemos ver cuán importantes son los modelos en cualquier aplicación, ya que es responsable de cualquier acción dinámica que suceda en una aplicación. Ahora que tenemos una comprensión bastante clara de las responsabilidades del Modelo, así como de la Vista y el Controlador, vamos a sumergirnos en la implementación de los Modelos en nuestra aplicación.


Paso 1: Configuración de la aplicación Zend para conectarse a una base de datos

Lo primero que tendremos que hacer es hacer que nuestra aplicación Zend se conecte a una base de datos. Afortunadamente, el comando zf puede encargarse de eso. Abre tu símbolo del sistema (o terminal), cd en tu carpeta thenextsocial, y escribe lo siguiente:

Si es correcto, deberías obtener una salida similar a:

Además, deberías ver dos nuevas líneas dentro de tu archivo application.ini:

Podemos ver claramente que la directiva SetEnv APPLICATION_ENV establece el entorno de nuestra aplicación. Si y cuando movemos la aplicación a otro entorno, esto debería ser lo único que debemos cambiar. Esto garantiza que todo en lo que se basa nuestra aplicación para trabajar está definido en application.ini, lo que garantiza que nuestra aplicación no se base en ninguna configuración externa. Esto ayuda a eliminar el problema "funciona en mi máquina de desarrollo, ¿por qué no funciona en el servidor de producción?".


Paso 2 - Crear la base de datos y algunas tablas

Antes de crear tu primer modelo para la aplicación, necesitaremos una base de datos que el modelo representará primero. Comencemos con algo simple: una tabla User, donde guardaremos todos los usuarios registrados para TheNextSocial.

Inicia sesión en tu base de datos MySQL y crea una base de datos llamada thenextsocial. Una vez que se haya creado, ejecuta la siguiente consulta para crear una tabla User y una tabla adjunta de configuración de usuario llamada User Settings:

Estas consultas SQL deben crear dos tablas. Una tabla User con las siguientes columnas:

  • id - una ID única para cada usuario
  • email - la dirección de correo electrónico del usuario, también único.
  • password - la contraseña del usuario, que tendremos encriptada.
  • salt - un sal aleatorio, que utilizaremos para marcar la contraseña del usuario
  • date_created - la fecha y hora en que se creó el registro de usuario

Y una tabla user_settings, donde almacenaremos cualquier configuración relacionada con el usuario, con las columnas:

  • id - una ID única para cada configuración
  • user_id - el user_id que es una clave externa para user.id
  • name - una cadena de texto que representa la configuración
  • value -el valor de la configuración

Vale la pena tener en cuenta que la tabla User Settings y User comparte una relación de uno a varios, lo que significa que un solo registro de usuario puede relacionarse con varios registros de configuración de usuario. Esto facilitará el almacenamiento de cualquier tipo de información relacionada con un usuario, por ejemplo, tu nombre o foto de perfil.

Ahora que tenemos algunas tablas para jugar, aprendamos cómo crear nuestro primer modelo: el modelo User.


Paso 3 - Creando tu primer modelo

El patrón de diseño DAO

Al igual que con muchas aplicaciones, la forma habitual de utilizar los modelos make en Zend Framework es hacer uso de un patrón de diseño popular denominado patrón "DAO". En este patrón tenemos los siguientes componentes:

  • Table Data Gateway (DataSource) - Es la puerta de enlace de datos de la tabla (fuente de datos) que conecta tu aplicación con la fuente de datos, la tabla MySQL
  • Data Mapper (DataAccessObject) que mapea los datos recuperados de la base de datos y los asigna.
  • Objeto de datos (datos) - Data Object (Data) que representa una fila de nuestra base de datos, después de que el DataMapper le asigna los datos

Comencemos por crear una puerta de enlace de datos de tabla (Table Data Gateway) para la tabla de usuario utilizando la herramienta CLI de zf:

La zf create db-table toma en dos parámetros:

  • ClassName - el nombre de la clase
  • database_table - el nombre de la tabla

Abre el archivo User.php que se encuentra en la carpeta application/models/DbTable y debería verse así:

Ahora vamos a crear una clase Data Mapper. De nuevo, usando la herramienta CLI de zf:

El archivo UserMapper.php estará vacío en este momento, pero luego ingresaremos un código. Por ahora, necesitamos crear el objeto de datos, que es el modelo User:

Aquí tenemos tres métodos:

  • __construct() - Es el constructor para la clase. Una vez que se crea una instancia, crea una instancia de Table Data Gateway y la almacena
  • save(Application_Model_User $user_object): toma a Application_Model_User y guarda los datos del objeto en la base de datos
  • getUserById($id): toma un entero $id que representa una sola fila de la tabla de base de datos, lo recupera, luego devuelve un Application_Model_User con los datos asignados

Abre User.php y coloca el siguiente código en:

  • __construct($user_row): toma en un objeto Zend_Db_Table_Row opcional, que representa una fila de la base de datos, y asigna los datos a sí mismo
  • __set($name, $value): una función mágica que se encarga de configurar todos los atributos para el modelo.
  • __get($name): una función mágica que se encarga de obtener un atributo del modelo.

¡Vamos a probarlo! Si seguiste el tutorial anterior, debes tener un archivo IndexController.php. Ábrelo y pon este código que crea un nuevo usuario:

Ahora ve a http://thenextsocial.local/. Una vez que se cargue, verifica la tabla thenextsocial.user en MySQL y si todo funcionó, ¡deberías tener un nuevo registro de User!

A new User record!

¡Un nuevo registro de User!

Ahora, intentemos actualizar este registro. Vuelve a IndexController.php y actualiza el código para que coincida con lo siguiente:

Verifica la tabla MySQL nuevamente, ¡y deberías ver que el correo electrónico para el registro se ha actualizado!

Updated User record

Registro de User actualizado

¡Felicidades! ¡Has creado con éxito tu primer modelo en Zend Framework!


La Doctrina ORM

Introducción

Desde el sitio web de Doctrine ORM, http://doctrine-project.org/projects/orm:

Asignador relacional de objetos (ORM) para PHP que se encuentra sobre una capa de abstracción de base de datos potente (DBAL). Una de sus características clave es la opción de escribir consultas de base de datos en un dialecto SQL orientado a objetos patentado llamado Doctrine Query Language (DQL), inspirado en Hibernates HQL. Esto proporciona a los desarrolladores una poderosa alternativa a SQL que mantiene la flexibilidad sin requerir duplicación de código innecesaria.

Básicamente, la biblioteca ORM de Doctrine abstrae la mayoría, si no toda la implementación del Modelo para una aplicación. Algunas de las increíbles ventajas que descubrí al usar Doctrine con Zend Framework son:

  • Facilidad de usar, garantizado para reducir tu tiempo de desarrollo a la mitad
  • Funciona igual de bien con diferentes tipos de DB's con muy pocos ajustes necesarios. Por ejemplo, Doctrine me hizo muy fácil portar una aplicación en la que trabajé antes de usar MySQL para MSSQL
  • Una herramienta de scaffolding, llamada Doctrine_Cli, que crea modelos a partir de la base de datos muy rápidamente.

Para comenzar, debes descargar la biblioteca ORD de Doctrine primero desde su sitio. Estaré usando la versión 1.2.4. Ve a http://www.doctrine-project.org/projects/orm/1.2/download/1.2.4 y haz clic en el enlace Descargar paquete 1.2.4.

Downloading the Doctrine ORM

Descargando Doctrine ORM

Una vez descargado, ábrelo y extrae el contenido. Dentro, deberías ver la carpeta Doctrine-1.2.4 y un archivo package.xml. Ve dentro de la carpeta y deberías ver una carpeta Doctrine, un archivo Doctrine.php y un archivo LICENSE.

Doctrine download contents

Descargar contenidos

Copia la carpeta Doctrine y el archivo Doctrine.php y colócalo dentro de la ruta de inclusión de tu instalación de PHP. Si recuerdas cómo configuramos Zend Framework en el último tutorial, es muy probable que sea la misma carpeta en la que colocaste los archivos de la biblioteca Zend.

Doctrine library with Zend library in PHP's include_path

Librería Doctrine con la biblioteca de Zend en include_path de PHP

¡Ahora estamos listos para integrarlo con nuestra aplicación Zend! Comienza por abrir application.ini nuevamente y agrega la siguiente configuración dentro del bloque [development : production]:

Ahora que lo hemos configurado, abre el archivo Bootstrap.php de la aplicación. Encontrarás esto dentro de la carpeta thenextsocial/application.

Bootstrap.php

Bootstrap.php nos permite inicializar los recursos que podríamos usar en nuestra aplicación. Básicamente, todos los recursos que necesitamos para crear instancias deben ubicarse aquí. Nos adentraremos en esto con más detalle más adelante en la serie, pero por ahora, todo lo que necesitas saber es que el formato de los métodos aquí es el siguiente:

Dentro del archivo Bootstrap.php, agrega el siguiente código para inicializar Doctrine con la aplicación:

La configuración que he hecho aquí se basa en un Script que encontré en el pasado en http://dev.juokaz.com, que fue mantenido por Juozas Kaziukenas, uno de los miembros del equipo en el proyecto Doctrine. Lamentablemente, el blog ya se ha cerrado, por lo que no podré enlazarlo más. Además, ten en cuenta que tenemos otro método llamado _initAutoload(). Básicamente, esto inicializa el autocargador Zend, que cargará automáticamente todos los modelos generados dentro de la carpeta models. Esto nos ahorra la molestia de tener que incluir estos archivos uno por uno.

A continuación, debemos configurar el script CLI de Doctrine que usaremos para generar modelos automáticamente desde la base de datos. Vuelve a la carpeta thenextsocial y crea una carpeta llamada scripts. Dentro, crea un archivo llamado doctrine-cli.php y coloca lo siguiente dentro:

Vuelve a la carpeta models y elimina los archivos del modelo User que tenemos allí (si lo deseas, puedes moverlo a otra ubicación primero, pero no debería estar dentro de la carpeta). A continuación, abre tu símbolo del sistema (o terminal), cd a la carpeta scripts y escribe el siguiente comando:

Deberías ver algo como esto:

Expected Doctrine CLI output

Salida esperada de Doctrine CLI

Si todo salió bien, ¡comencemos a crear algunos modelos! Escribe lo siguiente:

Ahora deberías ver el siguiente resultado:

Generating Models using Doctrine CLI

Generando modelos usando Doctrine CLI

Si lo hiciste, revisa nuevamente la carpeta de tus modelos y deberías ver algunos modelos nuevos como User y UserSettings que han sido generados por Doctrine.

Generated Models!

¡Modelos Generados!

Si abres los archivos, no verás mucho dentro. La mayoría de los códigos para los modelos están resumidos en la biblioteca Doctrine. Al extender la clase Doctrine_Record, tenemos disponibles para nosotros muchos métodos precompilados de la biblioteca. Abre IndexController.php de nuevo y reemplaza el código de prueba anterior con lo siguiente:

Una vez hecho esto, vuelve a http://thenextsocial.local. Si la página se carga, comprueba tu tabla MySQL y deberías ver que se ha insertado un nuevo registro de Usuario en User.

User record via Doctrine ORM

Registro de usuario a través de Doctrine ORM

Ahora, probemos cosas más complicadas: recuperar un usuario existente a través de métodos Doctrine precompilados y actualizarlo. Actualiza el código para que se vea así:

El método findOneByEmailAndPassword() es un método conveniente creado previamente por Doctrine para facilitar la selección de una fila de la base de datos. Lo mejor de esto es que puedes combinar columnas de tablas en el método. Por ejemplo, puedes llamar a algo como findOneByIdAndNameAndPasswordAndSalt() y ¡seguirá funcionando!

Updating a User record via Doctrine ORM

Actualización de un registro de usuario a través de Doctrine ORM

Hay mucho más que podemos hacer ahora que usamos Doctrine ORM para la implementación del Modelo de la aplicación. Cosas como el lenguaje de consulta de Doctrine (DQL), aprovechando las relaciones del modelo y generando modelos desde YAML. Para el resto de la serie, usaremos Doctrine ORM para la implementación del Modelo de la aplicación, ¡así que en realidad aprenderás dos cosas de la serie en lugar de solo una! ¡Puntuación!


Conclusión

Por ahora, deberías poder saber lo siguiente:

  • Qué son los “modelos”
  • Conectando tu aplicación Zend a una base de datos
  • Cómo funciona application.ini
  • El patrón de diseño DAO
  • Creación de modelos utilizando la herramienta ZF CLI
  • Dónde descargar Doctrine ORM y cómo instalarlo
  • Integración de Doctrine ORM con tu aplicación Zend
  • El Bootstrap.php
  • Generando modelos usando la herramienta CLI de Doctrine
  • Uso básico de los modelos generados con Doctrine.

Ahora que sabes cómo implementar los Modelos en una aplicación potenciada de Zend Framework, tienes el conocimiento para crear sitios web dinámicos. Intenta jugar con la aplicación, crea algunos Controladores y modelos nuevos que lean, actualicen, guarden y eliminen de la base de datos.

En nuestro próximo tutorial, aprenderemos sobre algunos componentes de uso frecuente de la biblioteca de Zend Framework, los componentes Zend_Auth y Zend_Acl y compilaremos el sistema de autenticación de TheNextSocial.

Hasta entonces, permanece atento y recuerda que todo el código utilizado aquí está disponible en el repositorio GitHub de TheNextSocial.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.