1.3. Entendiendo el entorno

El framework gvHIDRA sigue una arquitectura MVC. Esta arquitectura tiene como objeto dividir en capas diferentes la lógica de negocio, la lógica de control y la presentación. Con ello conseguimos desarrollos más robustos y fuertes ante los cambios de requisitos. El siguiente diagrama muestra como funciona de forma esquemática la relación entre capas:

Esta división en capas se plasma físicamente esta división dentro de una aplicación gvHIDRA. Concretamente, para hacer un mantenimiento, el programador tendrá que trabajar en las siguientes partes de la estructura:

Aquí tenemos un esquema donde lo podemos ver un ejemplo de aplicación con las capas que componen la arquitectura MVC.

A estas capas, falta añadir la interfaz con el usuario, las pantallas. Para la realización de las mismas, gvHIDRA hace uso de smarty y de unos plugins propios. Estos fichero, se ubican en el directorio templates y contienen la definición de una ventana con todos sus componentes.

Una vez vista la estructura física de una aplicación, es conveniente ver los componentes internos del framework a través del flujo interno que provoca una petición de pantalla. En el siguiente diagrama de secuencia, hemos colocado algunos de los actores que intervienen en el tratamiento de una petición así como sus operaciones.

  1. El flujo se inicia con la aparición de un estímulo de pantalla lanzado por el usuario.

  2. Este estímulo es transmitido al controler (en nuestro caso phrame) en forma de acción. Ahora es phrame quien, consultado con el fichero de mapeos (fichero mappings.php) es capaz de conocer que clase es la encargada de gestionar la acción. Una vez conocida la clase, la "levanta" y le cede el control pasándole todos los datos de la petición.

  3. La clase (conocida como clase manejadora) una vez tiene el control realiza varios pasos.

    • Reconecta de forma automática a la base de datos (en el caso de que exista).

    • Parsea el contenido de la petición (REQUEST) encapsulando en un objeto iterador que agrupa el contenido en matrices por operación.

    • Lanza las distintas operaciones. Estas operaciones se extienden con el comportamiento extra que añade el programador. Es decir, si lanzamos una acción de borrado, el framework realiza las operaciones necesarias para eliminar la tupla de la base de datos y el usuario tiene dos puntos de extensión opcional de dicho comportamiento: antes de borrar (métodos pre: para validaciones) y después de borrar (métodos post: para operaciones encadenadas).

  4. Una vez finalizado todo el proceso, la clase manejadora devuelve un actionForward a phrame. Este lo descompone y se localiza la views seleccionada.

  5. Finalmente, el views recoge la información y, con la plantilla (fichero tpl de smarty) muestra la información en pantalla.