Framework

El lenguaje PHP se trata de un lenguaje de comandos del servidor cuyas características permiten la inclusión de diversos patrones basados en el modelo clásico MVC (Model View Controller) o Modelo-Vista-Controlador. Puesto que el lenguaje PHP tiene posibilidades de ser flexible y ampliable, durante los últimos años, se han ido incorporando una serie de patrones y ampliaciones para facilitar el desarrollo de aplicaciones Web. Estas nuevas inclusiones le permiten a los desarrolladores optar por diversos escenarios de desarrollos más sólidos y flexibles que contribuyen en mejoras tales como desarrollos rápidos, facilidades de manutención, bajos factores de acoplamiento, bajos costes, entre otras características.

MVC (Model View Controller)

Antes de explorar los Framework de PHP, es necesario entender que es el modelo MVC. El modelo MVC se trata de un estándar para el desarrollo de software de aplicaciones Web. El estándar cubre una serie de requerimientos fundamentales, tales como escala, bajos acoplamientos, modularidad, etc. Este modelo se divide en tres grandes áreas operativas. Véase la figura 1.

Figura 1 – Modelo Vista Control MVC

Modelo

El área llamada Modelo se trata de una sección donde se encuentra la capa de negocio y la interacción con las bases de datos. La capa de negocio proporciona muchas alternativas para el desarrollo interactivo entre las bases de datos y el modelo. Si bien en este curso hemos visto la interoperación entre PHP y MySQL, esta interoperatividad que propone el modelo permite el uso de otros gestores de bases de datos, tales como Oracle, SQLite, etc. Lo importante es comprender que el Modelo garantiza la interoperación entre la capa de negocio y el gestor de base de datos.

Si observa la figura 1, en la sección de Modelo, puede ver que se hace mención de consultas “Querys”, encapsulación, solicitudes y respuestas incluso el estado entre otras cualidades. En efecto, la capa de negocio permite construir estas negociaciones. Una consulta que es peticionada por la sección de Vista hacia la capa de negocio, establece un punto de petición de datos. Según las características de la petición el negocio, se establece la interacción con el gestor de base de datos y los datos, que más tarde, son manipulados de modo tal que el Modelo pueda devolverlos a las otras secciones de MVC, en este caso sobre el área de Vistas. Todos estos pasos serán orquestados por la sección de Control.

Vista

La sección Vista está relacionada directamente con la interfaz gráfica del usuario. La interfaz proporciona al usuario un punto de interacción con la aplicación. Por otra parte, a su vez, la sección Vista produce un punto de interacción con la sección del Modelo. Lo interesante de la sección Vista, es el factor de acoplamiento que existe entre la Vista y el Modelo que permite, entre otras cosas, la modularidad entre distintos tipos de interfaces. Por ejemplo, el uso de pantallas con objetos CGI, celulares, el uso de Applets de Java, módulos de plugins tales como Flash o Silverlight, etc., que enriquecen las interfaces gráficas y cuyos usos no alteran las otras secciones Modelo y Control.

En efecto, Ud., puede optar por varias de estas tecnologías sin que estas mismas alteren al Modelo. Además, se dice que es de alta convergencia puesto que Ud., podría considerar ambientes diversos de tecnologías gráficas sin alterar las características del Modelo y producir una alta convergencia para cada uno de los casos con la sección del Modelo. Por ejemplo, la interfaz gráfica de un celular y la de su pc. Ambas son totalmente distintas. Sin embargo, por ejemplo, ambas pueden realizar la misma funcionalidad y es la de accesar recursos de una base de datos.

Controlador

La sección de Control cumple la función de gestionar el comportamiento de las interacciones que surgen entre las secciones de Vista y del Modelo. A rasgos generales, la sección de Control mapea todas las actividades que ejecuta el usuario y la forma en cómo las secciones Vista-Modelo interactuarán entre sí. Todo el proceso de peticiones y de respuestas deben ser gestionadas de modo que la información pueda manipularse correctamente para cada etapa del modelo. La sección de Control dirige estos procesos y mantiene en sincronía las tareas que estos demandan al sistema.

El Porqué del Uso de Patrones MVC

El uso de patrones tiene mucha relevancia en varias áreas para el desarrollo. Por empezar, el desarrollo deja de ser un trabajo continuo, incluso aglutinado y pasa a ser un modelo más racional porque le permite colocar el proyecto y dividirlo entre tres áreas operativas. Al contar con áreas separadas, se facilitan varios factores de desarrollo, escala y manutención, etc.

Además, el patrón le permite que un equipo de desarrollo pueda dividir las tareas y cargar con responsabilidades separadas para acelerar los procesos de desarrollo. Esto beneficia al proyecto puesto que cada uno se aboca a su respectiva área, enfocándose en las áreas de forma eficiente en un lapso de tiempo paralelo durante el desarrollo de dicho proyecto.

Tipos de Framework

En la actualidad, existen una serie infinita de Framework, de hecho, mientras estoy escribiendo esto, están surgiendo cada vez más, nuevos patrones modelo. Esta diversidad permite al desarrollador optar por varias opciones y ajustarse a las necesidades que cada uno de estos proponen.

A continuación cito alguno de ellos o, al menos, los más importantes y conocidos en el mercado para el lenguaje PHP y ellos son los siguientes:

Achievo ATK - http://www.achievo.org/atk
Akelos Framework - http://www.akelos.org/
AModules3 - http://adevel.com/amodules3
Ambivalence - http://amb.sourceforge.net/
Aukyla PHP Framework - http://www.auton.nl/software/en/doxygen/index.html
Binarycloud - http://www.binarycloud.com/
Biscuit - http://ripcord.co.nz/biscuit/
Bitweaver - http://www.bitweaver.org/
Booby - http://www.nauta.be/booby
CakePHP - http://www.cakephp.org/
Castor - http://castor.2le.net/
Cgiapp - http://cgiapp.sourceforge.net/
CodeIgniter - http://codeigniter.com/
Copix - http://copix.aston.fr/
Core Enterprise PHP - http://sourceforge.net/projects/cep
FastFrame - http://www.codejanitor.com/
Fusebox - http://www.fusebox.org/
FuseLogic - http://www.haltebis.com/index/wakka/main/FuseLogic
Konstrukt - http://konstrukt.dk/
Kumbia - http://kumbia.sf.net/
Krysalis - http://www.interakt.ro/products/Krysalis/index.php
Inek - http://wiki.opensourcebox.de/index.php/Inek_Framework
InterJinn - http://www.interjinn.com/
Ismo - http://ismo.sourceforge.net/
Medusa - http://medusa.tigris.org/
Nexista - http://www.nexista.org/
P4A - http://p4a.crealabsfoundation.org/
PHP on Trax - http://phpontrax.com/
PHPulse - http://www.phpulse.com/
PhpMVC - http://www.phpmvc.net/
Popoon - http://www.bitflux.ch/developer/cms/popoon.html
Prado - http://www.xisc.com/
Qcodo - http://www.qcodo.com/
Rwfphp - http://www.rwfphp.org/
Seagull - http://seagull.phpkitchen.com/
Sitellite - http://www.sitellite.org/
SolarPHP - http://www.solarphp.com/
sQeletor - http://www.proyectofindecarrera.com/
Studs - http://www.mojavelinux.com/projects/studs/
struts4php - http://www.struts4php.org/
symfony - http://www.symfony-project.com/
TaniPHP - http://www.taniphp.org/
Tigermouse - http://tigermouse.sf.net/
web.framework - http://www.webframework.org/
Wolfden CMF - http://www.framework.wolfden.com.ua/
YII - http://www.yiiframework.com/
Zephyr Framework - http://zephyr-php.sourceforge.net/
Zoop Framewor - http://www.zoopframework.com/

Elección de un Framework Adecuado

Ante una diversidad muy amplia que ofrece el mercado del software, a veces resulta bastante difícil determinar cuál es el más apropiado y proceder con su elección. Cada Framework tiene sus pros y sus contras. De hecho, analizar cada uno de ellos en particular, podría resultar en una tarea bastante compleja y entiendo que tendría poco sentido ajustarlo a nuestro curso. Esto para nada significa que no se tengan en cuenta estas cuestiones en particular. Sin embargo, el debate que creo que no deja de ser más que interesante, pero por otro lado, escaparía totalmente a los objetivos de este curso.

En este curso conoceremos el Framework YII y veremos también CodeIgnitor de modo de que abarquemos dos Framework que, a mi modesto juicio, encierran características adecuadas para el curso que está haciendo.

Analizando un Caso Simple con MVC en PHP

El siguiente ejemplo se trata de un sencillo modo de enlistar artículos en un blog. Ver figura 1.

<php?

// Conexión a la base de datos.

$cn = mysql_connect('localhost', 'usuario', 'clave');

mysql_select_db('db', $cn);

// Consulta SQL para traer los artículos.

$resultado=mysql_query('SELECT fecha, titulo FROM articulo', $cn);

<h1>Listado de Articulos:</h1>

<table>

<tr><th>Fecha</th><th>Titulo</th></tr>
<php?

// Recorre el resultado pintando la fecha y titulo.

while ($fila = mysql_fetch_array($resultado, MYSQL_ASSOC))

{

echo "";

echo " ".$fila ['fecha'] ." ";

echo " ".$fila ['titulo'] ." ";

echo "";

}

</table>
<php?

// Cerramos la conexión.

mysql_close($cn);

Figura 1 – Código para Enlistar Artículos en un Blog

Si observa el código detenidamente podrá notar que en el mismo archivo fuente, se encuentran todas las funcionalidades juntas para la aplicación. Esta forma de desarrollar en el lenguaje PHP puede ser muy a menudo frecuente, pero encierra muchas desventajas. Por empezar, Ud., tiene todo el código en un archivo. Esto dificulta la manutención del mismo porque, si tuviera que realizar algún cambio o una actualización, inevitablemente, tendrá que modificar el único archivo fuente. También, cada parte vital del programa depende de ese archivo fuente y, por tanto, dificulta su interpretación.

En el ejemplo que tenemos, vemos que el código es más o menos sencillo, pero puede que se encuentre con soluciones más complejas y, en ese caso, las dificultades irán en aumento. En breve, cuanto más código se deba desarrollar, mayor será el grado de dificultades tanto en interpretación como en manutención, entre otras características.

Refactoreo de la Solución Usando un Patrón MVC

Para normalizar el programa fuente del citado ejemplo, hemos de incluir el modelo de patrón MVC cómo alternativa para una solución más racional y eficiente. Por empezar, tomaremos el código y lo dividiremos en tres áreas perfectamente especificadas. Cada una de estas cumplirá la función de proveer los recursos necesarios para mejorar la solución y obtener una aplicación adecuada al estándar propuesto.

Fase Controlador

En la siguiente sección se describe el sector que se encargará de gestionar el comportamiento de esta aplicación. Ver figura 2.

require('modelo.php');

$articulos = getArticulos();

require('vista.php');

Figura 2 – Fase de Control – control.php

Fase Vista

En la siguiente fase se describe el código para las vistas en la pantalla de interfaz del usuario y cómo este verá e interactuará con dicha vista. Ver figura 3.

<h1>Listado de Artículos</h1>

<tr><th>Fecha</th><th>Titulot</th></tr>
</thead>
<tbody>

<php? foreach($articulos as $articulo): ?>

<tr>

<tr>

<php? endforeach; ?>
</tbody>

</table>

Figura 3 – Fase de Vista – vista.php

Fase Modelo

En la siguiente fase se crea las negociaciones más adecuadas para establecer un punto de contacto entre la base de datos y la aplicación. Ver figura 4.

<php?

function getArticulos() {

$cn = mysql_connect('localhost', 'usuario', 'clave');

mysql_select_db('db', $cn);

$resultado = mysql_query(
'SELECT fecha, titulo FROM articulo', $cn);

$articulos = array();

while($articulo = mysql_fetch_assoc($resultado)) {

$articulos[] = $articulo;

}

mysql_close();

}

Figura 4 – Fase de Modelo – modelo.php

Refactorizando el Área de Modelo

En la fase de Modelo hemos construido el código con la consulta para establecer el negocio con la base de datos. Esto es válido y muy útil, sin embargo, se puede plantear un refactoreo más. Podría dividir esta etapa en dos secciones. Una sección la llamaremos Capa Abstracta y la otra sección la llamaremos Capa de Acceso de Datos. A continuación, muestro los dos códigos respectivos. Véase la figura 5 y 6 respectivamente.

function crearConexion($servidor, $usuario, $clave){

return mysql_connect($servidor, $usuario, $clave);

}

function cerrarConexion($cn){

mysql_close($cn);

}

function consulta($consulta, $base_datos, $cn){

mysql_select_db($base_datos, $cn);

return mysql_query($consulta, $cn);

}

function getResultado($resultado, $tipo = MYSQL_ASSOC){

return mysql_fetch_array($resultado, $tipo);

}

Figura 5 – Abstracción de Datos - abstrac.php

function getTodosLosArticulos(){

$cn = crearConexion('localhost', 'usuario', 'clave');

$resultado = consulta(
'SELECT fecha, titulo FROM articulo', 'db', $cn);

$articulos = array();

while ($articulo = getResultado($resultado)){

$articulos[] = $articulo;

}

cerrarConexion($cn);

return $articulos;

}

Figura 6 – Acceso a Datos – access.php

Esta separación entre estas dos capas tiene muchas ventajas significativas. Una de ellas por ejemplo es la reutilidad, es decir, que esta porción del código podría estar disponible para otras aplicaciones que requieran de recursos similares para establecer una negociación similar a la expuesta. Esto ahorra cierta cantidad de código cuando se desarrolla o amplía su aplicación. Otro factor relevante es que podría resultar fácil la adaptación para un posible uso para otros gestores de bases de datos que demandan otras clases de tipos de librerías para el acceso y manipulación de datos. Entre otras características y una de las más importantes es que esta forma de particionar el código facilite enormemente su manutención.

Desarrollado y redactado por Wagner, Ariel Alejandro

Job Systems Solutions

Desarrollo de Software - Ariel Alejandro Wagner

Páginas

viernes, 17 de marzo de 2017

Patrones en MVC en PHP