Ejemplo de aplicación para un Blog sobre Zend Framework - Parte 2: La arquitectura MVC de la aplicación
sábado, 30 de agosto de 2008Posted by
Lid Pud Saya
0 Comments
Buscando buenos textos para documentar experiencias con Zend Framework, me encuentro con una serie de artículos muy buenos para practicar, los textos originales se encuentran en inglés y para desgracia nuestra, el blog que los contenia (http://blog.astrumfutura.com) ya no existe, así que estoy haciendo un barrido por Internet para poder recopilarlos de nuevo, a medida que los voy probando para asegurar compatibilidad con la mas reciente versión del ZF.
Parte 2: Esta si estaba en inglés, entonces a traducir, o al menos hare lo que se pueda, cualquier corrección estará bien recibida. :)
Si está esperando a que el código fuente aparezca (Yo diria, esta en el lugar equivocado jejeje), esto solo sucederá en la próxima entrega.
Anteriormente: Parte 1 Introducción y planificación
Después de hablar con varios usuarios acerca de como empezar con un framework, encontré que muchos no tienen un conocimiento avanzado de lo que denominariamos "piedra angular" de un framework para aplicaciones web hoy en dia, hablo de: El patrón de diseño Modelo-Vista-Controlador, así que vamos a saber mas sobre él, y primero, empezamos buscando en PHP.
Como antecendentes, considere el tradicional y todavia popular enfoque para escribir una aplicación en PHP. Por lo general tomas un enfoque llamado "el controlador de la página". Cada HTML de su aplicación puede tener su propio archivo PHP dedicado - a menudo esto termina en muchas páginas HTML por archivo PHP, pero solo si esas páginas son lo suficientemente similares (e.j: formularios y procesamiento del formulario son tipicos) tal que la relación está formada fuera de la necesidad de reutilizar el código en el mismo archivo. Con frecuencia, estas páginas comparten una colección de funciones, clases y constantes, Por jemplo, todas las páginas podrian neceistar Smarty, o una conexión a una base de datos o incluso quizás un modelo para recoger los datos de Usuarios, ACL, etc.
El problema es que en este escenario es muy dificil (pero no imposible) gestioanr el crecimiento y el cambio. Cada cambio y cada nueva característica requiere nuevo código. Cuando termina de poner el nuevo código, este se convierte en una enorme preocupación. Puede que necesite añadir varios cambios a varias piezas de la lógica de la aplicación, pero entonces se encuentra con que la lógica se encuentra dispersa a través de múltiples archivos PHP, Tal vez descubra que su conexión reusable a bases de datos ahora tiene sentencias SQL en 12 archivos, que ahora es necesario hacer referencia a un nuevo campo en la tabla. Puede imaginar la propagación de pequeños cambios múltiples archivos, finalmente la explosión de manera exponencial hasta que terminan en una situación donde el costo de cambio excede con mucho los beneficios. Este es el punto en que un proyecto esta simplemente estancado a pesar del entusiasmo de sus desarrolladores, y para ser claros, he caido en esa trampa anteriormente ;-). lo hecho, hecho está, descubrí el placer de la programación Orientada a Objetos y reformé mis prácticas.
El Modelo-Vista-Controlador
El patrón Modelo-Vista-Controlador (o MVC como es abreviado con frecuencia) es una solución general a la pregunta de como separar las responsabilidades en una aplicación y en ciero modo altamente estructurada. El nombre del patrón menciona las tres separaciones: Modelo, Vista y Controlador. Aunque MVCpodría parecer uno de esos conceptos esotéricos en programación, es actualmente un concepto muy simple. Usted recoge algunos trozos de funcionalidad, determina su propósito y la asigna a una de las tres separaciones y a continuación a una clase específica. Una vez que todo está dividido correctamente, termina con los pedazos pequeños que sean reutilizables, centralizados, accesibles y que encajen dentro de la construcción de bloques won un API Abstracto - trabajando ahora con APIs abstraidos hace de los cambios incrementales algo extremadamente simple (Si lo hace correctamente por supuesto ;-)). Con todo cuidadosamente organizado dentro de objetos con responsabilidades específicas el costo del cambio es reducido significativamente (Que es en realidad todo el punto que queremos cambiar para que sea barato y fácil).
Obviamente no estoy cubriendo todo el campo de la programación orientada a objetos. Pero esespero que el mensaje sea lo suficientemente claro. También la naturaleza orientada a objetos del Zend framework es en gran parte la razón por la que contiene tantos elementos. No solo tenemos el Zend_Controller - Tenemos Zend_Controller_Action, Zend_Controller_Router, Zend_ControllerFront, etc. cada rol específico o responsabilidad está cubierta por su propia clase. Esto sin duda se traduce en una abundancia de clases centradas a tal punto que puede llegar a ser dificil ver como trabajan todas las piezas - Pero honestamente, lo único que usted necesita es el API Abstraido y puede ignorar el resto a menos que realmente desee personalizar algo.
Para ser claros, el MVC es común como la suciedad, Es ampliamente utilizado en Zend Framework, Solar, Symphony, Ruby on Rails, merb, Django, Spring y un sin número de Frameworks. Se trata de un concepto para no olvidar a la hora de adoptar un framework para aplicaciones web en casi cualquier lenguaje.
El Modelo
El modelo es responsable de mantener el estado entre las peticiones HTTP y una aplicación web en PHP. Cualquier dato que debe preservarse entre las peticiones HTTP está destinado al segmento modelo de su aplicación. También incorpora las reglas y restricciones que rigen los datos, se denomina la "lógica de negocio". Por ejemplo si escribes la lógica de negocio para un modelo de órden en una aplicación para el manejo de inventarios, los controles internos de la compañia podrían dictar que órdenes de compra están sujetas a un único límite de compra en efectivo de € 500. Las compras de mas de € 500 tendrían que ser consideradas como acciones ilegales por el Modelo de órdenes (a menos que tal vez sea autorizado por alguien con una autoridad mas elevada). Por lo tanto, los modelos son el lugar lógico para el acceso a los datos, pero ta,biñen podrían actuar como una ubicación centralizada para examinar, verificar y hacer las manipulaciones finales de los datos, antes de que sean almacenados, e incluso después de ser recuperados.
La vista
La vista es la responsable de la generación de la interfaz de usuario para una aplicación. En PHP, a menudo está estrictamente definida como donde son puestos todo el HTML presentacional. Si bien esto es cierto, es también el lugar donde se peude crear un sistema de generación dinámica de HTML, RSS, XML, JSON o incluso nada mas que todo lo que va a ser enviado al navegador cliente o aplicación.
Normalmente, la vista está organizada dentro de plantillas, pero también puede ser simplemente lo devuelto por la función "echo" de php o manipulados por el controlador antes de la salida. Es esencial recordar que la Vista no es solo un formato de archivo, sino que tambien incluye todo el código PHP o análisis de etiquetas usados para organizar, filtrar, decorar y manipular el formato basado en datos extraidos de uno o varios modelos (o como es a menudo, lo que es pasado del modelo a la vista por el controlador).
En una nota al lado, este blog no va a utilizar Smarty. Smarty ha respetado la historia en PHP, pero tiene garves deficiencias una vez que usted comience a pensar en la vista como un rompecabezas de docenas de piezas reutilizables arrastradas junto a un único diseño global. En efecto, este método de administración de la Vista está estrechamente relacionada a la Programación Orientada a Objetos como un concepto en el que se usa a PHP como lenguaje de plantillas, se vuelve casi inevitable. Eso no sin un costo (¿Todos los diseñadores saben PHP?) pero es un costo manejable.
El controlador
Los controladores son engañosamente simples en comparación con los otros. La función principal del controlador es controlar y delegar. En una típica petición PHP a una arquitectura MVC, el controlador toma lo que se ingresó el usuario, supervisa el filtrado de esa información, validación y procesamiento de la entrada, administra el modelo, y finalmente delega la salida para que sea generada por la vista (Opcionalemente lo pasa a uno o mas modelos requeridos para procesar la plantilla actual). El controlador también tiene un única diferencia respecto a otras formas de arquitecturas en PHP, ya que solo requiere de un único punto de entrada en la aplicación - cas inevitablemente index.php.
El Controlador vs El Modelo
Una vista rápida de MVC no estaría completa sin una breve meción de por lo menos una diferencia muy común en aplicaciones MVC. Tomo prestado un término, Esta es la idea de un Modelo Gordo y un controlador Flaco.
Un modelo Gordo, es un modelo que tiene la mayor cantidad de lógica de negocio y manipulación de datos como puedan caber en ella. El resultado es una gran masa de lógica reutilizable y accesible desde cualquier controlador. Esto, en teoría, resulta en un controlador Flaco - cuando toda la lógica se incluye dentro de un modelo adecuado detrás de algunos APIs, el Controlador de tamaño promedio debería ser reducido, Menos código controlador, menos código ordinario oculto en lo que un controlador realiza.
Lo contrario es un modelo delgado y un Controlador Gordo - La lógica de negocio está dentro del controlador que obviamente incrementa su tamaño, y en segundo lugar significa que el código no es reutilizable (a menso que decida reutilizar el controlador desde otro controlador - que rara vez es una buena idea eficientemente sabia).
Conjuntamente, estos son los tres segmentos de una aplicación que implementa un arquitectura Modelo-Vista-Controlador. Es una solución ampliamente reconocida para aplicaciones wen y es evidente en la mayoría de la actual generación de Frameworks para muchos lenguajes de programación.
En el Zend Framewok, estass tres separaciones son representadas por los componentes Zend_Db, Zend_View y Zend_Controller. Estará escuchando mucho sobre estos tres y las clases que los componen en los capítulos que vienen. En conjunto, estos constituyen la columna vertebral de la arquitectura MVC del Zend Framework y se basa mucho en las mejores prácticas.
El Modelo-Vista-Controlador fue utilizado originalmente para promover la "separación de las intereses" en las aplicaciones de escritorio con interfaz gráfica. Al separar cada interés dentro de una capa independiente de la aplicación. que dio lugar a una disminución del acoplamiento que a su vez hizo mas fácil el diseño, escritura, pruebas y mantenimiento de las aplicaciones. Aunque las aplicaciones con Interfaz gráfica de usuario (GUI) se han apartado del MVC en los últimos años, ha demostradado ser altamente efectivo cuando se implementa en las aplicaciones Web.
En el Framewok, este añade un montón de estructuras previsibles desde cada segmento del MVC para que cualquier petición soportada este aparte dentro de su propio grupo de archivos. El controlador está representado por las subclases del Zend_Controller_Front y Zend_Controller_Action, El modelo por subclases de Zend_Db_Table y la vista por archivos de plantillas .phtml y View Helpers. El Zend Framework gestiona la organización de cada uno de ellos en el panorama general, dejandote libre para enfocarse solo en esas agrupaciones sin preocuparse de todo el código que resulta al combinarsen.
En cierto sentido es como construir una casa donde los cimientos, las paredes y el cableado interior y fontanería ya están en su lugar, y todo lo que queda por realizar es la decoración interior y un techo. Puede tomar algún tiempo para aprender a decorar y techar las secciones que ya están listas, pero una vez que has aprendido como hacerlo, después las casas estarán terminadas mucho mas rápido.
En Conclusión
Como he dicho, esto es muy brevemente una comprensión del MVC. No se trata de una exhaustiva, así que sientase libre para ejecutar unas cuantas búsquedas en Google y leer acerca del tema. Para los desarrolladores de aplicaciones Web, la lectura acerca del MVC nunca es un desperdicio. Hay un enorme cuerpo de pensamientos existentes que abarcan temas que van desde la realización de pruebas para MVC hasta que estilos de MVC funcionan mejor para diferentes situaciones.
Siguiente: Investigaremos un ejemplo de "Hola mundo" que no es el ejemplo mas simple posible, ya que ilustra algunas normas de limpieza para mantener este sencillo ejemplo lo mas ordenado y maleable posible.
Si. tendrá código PHP real :-)
------------------------------------------ FIN
Parte 2: Esta si estaba en inglés, entonces a traducir, o al menos hare lo que se pueda, cualquier corrección estará bien recibida. :)
Si está esperando a que el código fuente aparezca (Yo diria, esta en el lugar equivocado jejeje), esto solo sucederá en la próxima entrega.
Anteriormente: Parte 1 Introducción y planificación
Después de hablar con varios usuarios acerca de como empezar con un framework, encontré que muchos no tienen un conocimiento avanzado de lo que denominariamos "piedra angular" de un framework para aplicaciones web hoy en dia, hablo de: El patrón de diseño Modelo-Vista-Controlador, así que vamos a saber mas sobre él, y primero, empezamos buscando en PHP.
Como antecendentes, considere el tradicional y todavia popular enfoque para escribir una aplicación en PHP. Por lo general tomas un enfoque llamado "el controlador de la página". Cada HTML de su aplicación puede tener su propio archivo PHP dedicado - a menudo esto termina en muchas páginas HTML por archivo PHP, pero solo si esas páginas son lo suficientemente similares (e.j: formularios y procesamiento del formulario son tipicos) tal que la relación está formada fuera de la necesidad de reutilizar el código en el mismo archivo. Con frecuencia, estas páginas comparten una colección de funciones, clases y constantes, Por jemplo, todas las páginas podrian neceistar Smarty, o una conexión a una base de datos o incluso quizás un modelo para recoger los datos de Usuarios, ACL, etc.
El problema es que en este escenario es muy dificil (pero no imposible) gestioanr el crecimiento y el cambio. Cada cambio y cada nueva característica requiere nuevo código. Cuando termina de poner el nuevo código, este se convierte en una enorme preocupación. Puede que necesite añadir varios cambios a varias piezas de la lógica de la aplicación, pero entonces se encuentra con que la lógica se encuentra dispersa a través de múltiples archivos PHP, Tal vez descubra que su conexión reusable a bases de datos ahora tiene sentencias SQL en 12 archivos, que ahora es necesario hacer referencia a un nuevo campo en la tabla. Puede imaginar la propagación de pequeños cambios múltiples archivos, finalmente la explosión de manera exponencial hasta que terminan en una situación donde el costo de cambio excede con mucho los beneficios. Este es el punto en que un proyecto esta simplemente estancado a pesar del entusiasmo de sus desarrolladores, y para ser claros, he caido en esa trampa anteriormente ;-). lo hecho, hecho está, descubrí el placer de la programación Orientada a Objetos y reformé mis prácticas.
El Modelo-Vista-Controlador
El patrón Modelo-Vista-Controlador (o MVC como es abreviado con frecuencia) es una solución general a la pregunta de como separar las responsabilidades en una aplicación y en ciero modo altamente estructurada. El nombre del patrón menciona las tres separaciones: Modelo, Vista y Controlador. Aunque MVCpodría parecer uno de esos conceptos esotéricos en programación, es actualmente un concepto muy simple. Usted recoge algunos trozos de funcionalidad, determina su propósito y la asigna a una de las tres separaciones y a continuación a una clase específica. Una vez que todo está dividido correctamente, termina con los pedazos pequeños que sean reutilizables, centralizados, accesibles y que encajen dentro de la construcción de bloques won un API Abstracto - trabajando ahora con APIs abstraidos hace de los cambios incrementales algo extremadamente simple (Si lo hace correctamente por supuesto ;-)). Con todo cuidadosamente organizado dentro de objetos con responsabilidades específicas el costo del cambio es reducido significativamente (Que es en realidad todo el punto que queremos cambiar para que sea barato y fácil).
Obviamente no estoy cubriendo todo el campo de la programación orientada a objetos. Pero esespero que el mensaje sea lo suficientemente claro. También la naturaleza orientada a objetos del Zend framework es en gran parte la razón por la que contiene tantos elementos. No solo tenemos el Zend_Controller - Tenemos Zend_Controller_Action, Zend_Controller_Router, Zend_ControllerFront, etc. cada rol específico o responsabilidad está cubierta por su propia clase. Esto sin duda se traduce en una abundancia de clases centradas a tal punto que puede llegar a ser dificil ver como trabajan todas las piezas - Pero honestamente, lo único que usted necesita es el API Abstraido y puede ignorar el resto a menos que realmente desee personalizar algo.
Para ser claros, el MVC es común como la suciedad, Es ampliamente utilizado en Zend Framework, Solar, Symphony, Ruby on Rails, merb, Django, Spring y un sin número de Frameworks. Se trata de un concepto para no olvidar a la hora de adoptar un framework para aplicaciones web en casi cualquier lenguaje.
El Modelo
El modelo es responsable de mantener el estado entre las peticiones HTTP y una aplicación web en PHP. Cualquier dato que debe preservarse entre las peticiones HTTP está destinado al segmento modelo de su aplicación. También incorpora las reglas y restricciones que rigen los datos, se denomina la "lógica de negocio". Por ejemplo si escribes la lógica de negocio para un modelo de órden en una aplicación para el manejo de inventarios, los controles internos de la compañia podrían dictar que órdenes de compra están sujetas a un único límite de compra en efectivo de € 500. Las compras de mas de € 500 tendrían que ser consideradas como acciones ilegales por el Modelo de órdenes (a menos que tal vez sea autorizado por alguien con una autoridad mas elevada). Por lo tanto, los modelos son el lugar lógico para el acceso a los datos, pero ta,biñen podrían actuar como una ubicación centralizada para examinar, verificar y hacer las manipulaciones finales de los datos, antes de que sean almacenados, e incluso después de ser recuperados.
La vista
La vista es la responsable de la generación de la interfaz de usuario para una aplicación. En PHP, a menudo está estrictamente definida como donde son puestos todo el HTML presentacional. Si bien esto es cierto, es también el lugar donde se peude crear un sistema de generación dinámica de HTML, RSS, XML, JSON o incluso nada mas que todo lo que va a ser enviado al navegador cliente o aplicación.
Normalmente, la vista está organizada dentro de plantillas, pero también puede ser simplemente lo devuelto por la función "echo" de php o manipulados por el controlador antes de la salida. Es esencial recordar que la Vista no es solo un formato de archivo, sino que tambien incluye todo el código PHP o análisis de etiquetas usados para organizar, filtrar, decorar y manipular el formato basado en datos extraidos de uno o varios modelos (o como es a menudo, lo que es pasado del modelo a la vista por el controlador).
En una nota al lado, este blog no va a utilizar Smarty. Smarty ha respetado la historia en PHP, pero tiene garves deficiencias una vez que usted comience a pensar en la vista como un rompecabezas de docenas de piezas reutilizables arrastradas junto a un único diseño global. En efecto, este método de administración de la Vista está estrechamente relacionada a la Programación Orientada a Objetos como un concepto en el que se usa a PHP como lenguaje de plantillas, se vuelve casi inevitable. Eso no sin un costo (¿Todos los diseñadores saben PHP?) pero es un costo manejable.
El controlador
Los controladores son engañosamente simples en comparación con los otros. La función principal del controlador es controlar y delegar. En una típica petición PHP a una arquitectura MVC, el controlador toma lo que se ingresó el usuario, supervisa el filtrado de esa información, validación y procesamiento de la entrada, administra el modelo, y finalmente delega la salida para que sea generada por la vista (Opcionalemente lo pasa a uno o mas modelos requeridos para procesar la plantilla actual). El controlador también tiene un única diferencia respecto a otras formas de arquitecturas en PHP, ya que solo requiere de un único punto de entrada en la aplicación - cas inevitablemente index.php.
El Controlador vs El Modelo
Una vista rápida de MVC no estaría completa sin una breve meción de por lo menos una diferencia muy común en aplicaciones MVC. Tomo prestado un término, Esta es la idea de un Modelo Gordo y un controlador Flaco.
Un modelo Gordo, es un modelo que tiene la mayor cantidad de lógica de negocio y manipulación de datos como puedan caber en ella. El resultado es una gran masa de lógica reutilizable y accesible desde cualquier controlador. Esto, en teoría, resulta en un controlador Flaco - cuando toda la lógica se incluye dentro de un modelo adecuado detrás de algunos APIs, el Controlador de tamaño promedio debería ser reducido, Menos código controlador, menos código ordinario oculto en lo que un controlador realiza.
Lo contrario es un modelo delgado y un Controlador Gordo - La lógica de negocio está dentro del controlador que obviamente incrementa su tamaño, y en segundo lugar significa que el código no es reutilizable (a menso que decida reutilizar el controlador desde otro controlador - que rara vez es una buena idea eficientemente sabia).
Conjuntamente, estos son los tres segmentos de una aplicación que implementa un arquitectura Modelo-Vista-Controlador. Es una solución ampliamente reconocida para aplicaciones wen y es evidente en la mayoría de la actual generación de Frameworks para muchos lenguajes de programación.
En el Zend Framewok, estass tres separaciones son representadas por los componentes Zend_Db, Zend_View y Zend_Controller. Estará escuchando mucho sobre estos tres y las clases que los componen en los capítulos que vienen. En conjunto, estos constituyen la columna vertebral de la arquitectura MVC del Zend Framework y se basa mucho en las mejores prácticas.
El Modelo-Vista-Controlador fue utilizado originalmente para promover la "separación de las intereses" en las aplicaciones de escritorio con interfaz gráfica. Al separar cada interés dentro de una capa independiente de la aplicación. que dio lugar a una disminución del acoplamiento que a su vez hizo mas fácil el diseño, escritura, pruebas y mantenimiento de las aplicaciones. Aunque las aplicaciones con Interfaz gráfica de usuario (GUI) se han apartado del MVC en los últimos años, ha demostradado ser altamente efectivo cuando se implementa en las aplicaciones Web.
En el Framewok, este añade un montón de estructuras previsibles desde cada segmento del MVC para que cualquier petición soportada este aparte dentro de su propio grupo de archivos. El controlador está representado por las subclases del Zend_Controller_Front y Zend_Controller_Action, El modelo por subclases de Zend_Db_Table y la vista por archivos de plantillas .phtml y View Helpers. El Zend Framework gestiona la organización de cada uno de ellos en el panorama general, dejandote libre para enfocarse solo en esas agrupaciones sin preocuparse de todo el código que resulta al combinarsen.
En cierto sentido es como construir una casa donde los cimientos, las paredes y el cableado interior y fontanería ya están en su lugar, y todo lo que queda por realizar es la decoración interior y un techo. Puede tomar algún tiempo para aprender a decorar y techar las secciones que ya están listas, pero una vez que has aprendido como hacerlo, después las casas estarán terminadas mucho mas rápido.
En Conclusión
Como he dicho, esto es muy brevemente una comprensión del MVC. No se trata de una exhaustiva, así que sientase libre para ejecutar unas cuantas búsquedas en Google y leer acerca del tema. Para los desarrolladores de aplicaciones Web, la lectura acerca del MVC nunca es un desperdicio. Hay un enorme cuerpo de pensamientos existentes que abarcan temas que van desde la realización de pruebas para MVC hasta que estilos de MVC funcionan mejor para diferentes situaciones.
Siguiente: Investigaremos un ejemplo de "Hola mundo" que no es el ejemplo mas simple posible, ya que ilustra algunas normas de limpieza para mantener este sencillo ejemplo lo mas ordenado y maleable posible.
Si. tendrá código PHP real :-)
------------------------------------------ FIN
Suscribirse a:
Enviar comentarios (Atom)