Modelo Vista Controlador

Os dejo con un breve resumen de lo que significa el patrón Modelo Vista Controlador, y que mostrará el tipo de arquitectura que se desarrollará en el Framework.
Antes de realizar todo el análisis de requisitos, creo que seria una buena idea conocer un poco mas a fondo que significa este patrón de diseño.

Los patrones de diseño dan al software un conjunto de subsistemas predefinidos, especifican reglas y reparten responsabilidades haciendo de guía en la implementación del software.

Por lo tanto, los patrones ofrecen respuestas a nivel de diseño a problemas que puedan surgir o que sean derivados del desarrollo de software. Algunos de los problemas son la falta de reusabilidad de código, la eficiencia de este, la dificultad de mantenimiento y escalabilidad de sistemas....

En nuestro caso concreto, la parte de software dentro del sistema que vamos a tratar son las interfaces de usuario gráficas (GUI), y vamos a dar una respuesta a problemas derivados de ella, sobre todo en los puntos de facilidad de desarrollo, escalabilidad, mantenimiento y separación de capas (lógica del negocio con la vista y el comportamiento de esta).

ORIGENES

Introducido inicialmente en la comunidad de desarrolladores de Smalltalk-80. El objetivo de este no es mas que, como hemos dicho previamente, mantener separadas las diversas capas del software, para la mejora en cuanto a corrección de fallos, escalabilidad y mantenimiento del código.

DESCRIPCION

La principal regla del patrón es la separación de la parte gráfica con la parte de negocio (a su vez, se podría añadir separación de la capa de negocio de la capa de almacenamiento). Así, la dependencia de código entre capas sera de un grado menor, facilitando su manipulación.

Ahora bien, como se estructura este patrón:

• Modelo: Esta sirve como representación específica de toda la información con la cual el sistema va a trabajar, y contiene la lógica de negocio, lo que nos asegurara la independencia de tenerla en la capa gráfica (se aplica las mismas reglas al mismo modelo) La lógica de datos nos puede llegar a asegurar la integridad de ellos y nos permitirá derivar nuevos datos.

• Vista: Realiza una representación del modelo en forma de interfaz gráfica. Esto sera lo que el usuario vera por pantalla.

• Controlador: Responde a eventos, invocados por el usuario y manipula el comportamiento en los cambios sobre el modelo, y también lo realizara sobre la vista (por ejemplo, cuando un modelo envíe un evento notificando una acción realizada, el controlador deberá saber que realizar al recibirlo).

Una representación del patrón seria como nos muestra la imagen inferior

Aun así, convendría una explicación mas real de como funciona el comportamiento del patrón contando desde la participación del usuario.

1. El usuario realiza una acción sobre la interfaz de usuario (pulsa un botón, por ejemplo "buscar").

2. El controlador gestiona la acción que el usuario ha ejecutado y por medio de un gestor de eventos (handler) realiza las acciones correspondientes.

3. En este caso, el controlador ha hecho una petición de búsqueda, se actualiza el modelo de forma coherente con la nueva información y se actualiza la vista con los nuevos datos.

4. La vista pide los nuevos datos al modelo para iniciarla y mostrarla.

5. El modelo notifica a los controladores asociados que su estado ha sido cambiado, por lo que estos actualizaran las vistas que tengan asociadas con el modelo.

Como se puede observar, todas estas acciones son el objetivo a implantar, permitiendo al usuario que pueda crear componentes controladores, de vista y modelo, que implementen este funcionamiento de forma tal que pueda ser abstraído de la mayor forma posible para que el desarrollador no necesite escribir código redundante en cada uno de los nuevos componentes, y solo necesite saber de unas pocas reglas que proporcionara el framework que implemente este patrón.

Si vamos al sitio de wikipedia donde se define http://es.wikipedia.org/wiki/Modelo_Vista_Controlador, podemos contar como hay varios frameworks implantados ya. El problema, es que no hay frameworks estandarizados para la creación de aplicaciones de escritorio. Por ejemplo, en Java tenemos Swing, que hace una implementación interna siguiendo parte de este modelo (internamente se separa el modelo del componente gráfico, por ejemplo un objeto JTable tiene asociado un modelo sobre el que trabajar). Pero no ofrece la posibilidad al desarrollador de que sus futuras aplicaciones utilizando Swing puedan seguir perfectamente esta arquitectura completamente. En si, el desarrollador podrá separar las diferentes capas, pero el nivel de trabajo que tendrá que hacer sera mayor y muchas veces poco eficaz, debido a que el objetivo principal de su trabajo esta orientado a desarrollar una aplicación de escritorio, no un framework que implemente este patrón (hay algún desarrollo propio, como el proyecto TikeSwing),.

He elegido la plataforma Mono y GTK# debido a que es un producto nuevo, que al estar en fase de desarrollo y expansión, el resultado del proyecto podrá tener mayor repercusión y también habrá una mayor implicación debido a la escasez de proyectos con el mismo objetivo.