En nuestra aplicación IDIS Groupware utilizamos los siguientes patrones arquitectónicos:
PATRÓN MVC:
Este patrón de presentación de alto nivel es la esencia de nuestra arquitectura porque es la estructura básica implantada por el framework Kumbia utilizado para desarrollar nuestra aplicación.
El patrón MVC permite hacer la separación de las capas de interfaz, modelo y lógica de control, teniendo como objetivo primordial la separación de la lógica de negocios de la lógica de diseño, representado de la siguiente forma:
- Vistas: Visualizan el modelo usando páginas Web e interactuando con los usuarios de estas.
- Modelos: Representan la información sobre la cual la aplicación opera, su lógica de negocio.
- Controladores: Responden a acciones de usuario e invocan cambios en las vistas o en los modelos según sea necesario.
Este patrón funciona de las siguiente manera: en una aplicación Web una petición se realiza usando HTTP y es enviado al controlador. El controlador puede interactuar de muchas formas con el modelo, luego el primero llama a la respectiva vista (interfaz de usuario) la cual obtiene el estado del modelo y lo muestra al usuario en una respuesta HTTP.
Kumbia proporciona este patrón por su ventaja en el desarrollo, ya que este se lleva a cabo en varios niveles y en caso de algún cambio sólo se manipula el nivel requerido sin tener que revisar entre código mezclado o código spaguetti. Además de ello, la división en capas reduce la complejidad, facilita la reutilización y acelera el proceso de ensamblar o desensamblar alguna capa, o sustituirla por otra distinta bajo la misma responsabilidad.
¿Cómo utilizamos el patrón MVC en Kumbia?
En Kumbia es sencillo aplicar el patrón MVC. Como vemos en el paquete kumbia ya se disponen las carpetas para los controladores, el modelo y las vistas:
Descripción de las carpetas:
./controllers: Es el directorio para colocar las clases controladoras, cuya extensión del archivo es .php.
./models: Es la carpeta donde colocamos las clases referentes al modelo y la lógica que las maneja. Esta capa utiliza el mapeo objeto/relacional para representar las entidades del modelo de datos en nuestras aplicaciones, sólo tenemos que hacer que cada clase herede de la clase ActiveRecord. Esta Clase ActiveRecord la utiliza Kumbia para la administración y funcionamiento de los modelos, y hace el mapeo teniendo en cuenta que las Tablas son las Clases, los Campos de estas tablas son los Atributos y los Registros son los Objetos de la Clase. El archivo de cada clase es de extensión .php.
./views: En esta carpeta va toda la presentación de la aplicación: Vistas, Layouts, Templates y Partials. Los archivos son de extensión .phtml.
Estos son los aspectos básicos a tener en cuenta:
1. Las clases controladoras en su nombre deben llevar el formato nombreController y extender (extends) de la clase ApplicationController.
2. Las clases que representan el modelo (en models) deben llamarse igual al nombre de la tabla en nuestra base de datos y deben extender (extends) de la clase ActiveRecord.
Importante: Para que pueda existir el mapeo mediante ActiveRecord la tabla sobre la base de datos debe tener el nombre del campo que representa su llave primaria como id.
3. En el directorio views se debe crear una carpeta con el nombre del controlador, por ejemplo para UsuarioController creamos la carpeta con el nombre “usuario”. El nombre de cada archivo vista debe ser igual al nombre de la función en el controlador que la invoca, es decir si en el controlador UsuarioController hay una función llamada create() debe haber en /views/usuario el archivo create.phtml.
Los anteriores numerales se plasman en la siguiente gráfica:
PATRÓN PAGE CONTROLLER:
En nuestra aplicación utilizamos el patrón Page Controller. Este patrón maneja una solicitud de una página específica (ventana) o una acción.
Las responsabilidades básicas de este controlador son:
- Decodificar la URL y extraer de un formulario de datos los datos para la acción.
- Crea y recurre a un modelo de objetos para procesar los datos.
- Determina qué vista debe mostrar la página de resultados, y remitirá la información del modelo a la misma.
¿Cómo hacemos uso de este patrón?
En nuestra aplicación, creamos un controlador, basándonos en este patrón, por cada CRUD (Create-Read-Update-Delete) que se realiza sobre una tabla de la base de datos. Este patrón nos va a gestionar todo el CRUD que se accede desde una página, es decir que maneja todas las solicitudes de esta página.
Por ejemplo, tenemos la gestión de usuarios:
En el pantallazo podemos observar que esta página proporciona toda la gestión de un usuario con las siguientes opciones:
- Buscar.
- Crear usuario.
- Eliminar usuario.
- Modificar usuario.
Ahora, observando las carpetas en la siguiente gráfica se determina que para el controlador UsuarioController, se tiene las funciones create, delete, edit e index que corresponden a crear el usuario, eliminar usuario, modificar usuario, y la búsqueda que está como función principal en el index.
En el pantallazo:
- El número uno (1) representa el controlador, para la gestión de usuarios.
- El número dos (2) es la representación de la Tabla usuarios en el modelo.
- En el número tres (3) se observa la carpeta usuario que por aspectos básicos del framework Kumbia se debe llamar igual al controlador, como se mencionó anteriormente. En este directorio se presentan las cuatro vistas que se generan por medio del controlador, cada vista a partir de la manipulación o acción sobre una única página que gestiona el page controller.
