MODELO VISTA CONTROLADOR (MVC)

1. ORIGENES DEL MVC (MODELO VIST A CONTROLADOR)

El modelo vista controlador fue descrito por primera vez en 1979 por Trygve Reenskaug trabajador de Smalltalk en laboratorios de investigación de Xerox.El Modelo-Vista-Controlador se creó para Smalltalk a finales de los setenta. A partir de entonces su uso se ha ido extendiendo cada día más para la construcción de sistemas software con interfaz gráfica. Su enorme uso ha provocado que haya también multitud de referencias al patrón Modelo-Vista-Controlador, que en muchas ocasiones son fuentes de confusión porque se utilizan distintos contextos de aplicación para el patrón, se tratan de conseguir objetivos distintos, los nombres de los componentes del patrón son los mismos pero con diferentes responsabilidades, los diagramas de clases y de secuencia son también diferentes. Además, hay referencias donde se dan ejemplos de implementación del patrón con sus particularidades, ya que la mayoría de los entornos de desarrollo de aplicaciones, sobre todo de aplicaciones web, dan “facilidades” para implementar el patrón Modelo-Vista-Controlador. A veces esto no es del todo bueno, ya que realmente no implementan de forma correcta la esencia del patrón y confunden aún más al lector, que utiliza estas implementaciones como ejemplo para aprender a usar el patrón Modelo-Vista-Controlador.[1]

MVC fue propuesto como una muy buena solución para el desarrollo en Smalltalk de interfaces gráficas en entornos de ventanas. Cada ventana estaba compuesta de una triada MVC. La vista se encargaba del dibujado de mapas de bits, el controlador atendía acciones del mouse y teclado, y el modelo guardaba el estado de la ventana y la información mostrada en ella. Cada vista esta asociada con un controlador y un modelo en su creación. Cualquier modelo podía ser asociado débilmente a cualquier vista, pero cada par controlador/vista siempre se mantenían asociados con su respectiva pareja. En realidad el controlador no se encargaba de manejar la lógica del negocio en la aplicación, su propósito era manejar la interacción del mouse y el teclado, y actualizar la vista acorde, lo cual no era una tarea trivial. El modelo podía ser compartido entre diferentes displays, por eso la necesidad de ser débilmente asociable, una necesidad que aún hoy persiste, pero no así para la asociación modelo/vista, ésta tenía un propósito diferente: el modelo debía poder notificar a las vistas asociadas sobre cambios que ocurrieran fuera de su entorno. [2]

Smalltalk: Sistema informático que permite realizar tareas de computación mediante la interacción con un entorno de objetos virtuales.

Trygve Reenskaug: (nacido en 1930) es un científico de la computación noruego. Formuló el modelo-vista-controlador de patrón de diseño de software para el GUI en 1979 durante su visita a Xerox Parc.

Por su propia admisión, "La parte más difícil fue a golpear a los nombres de las buenas para los diferentes componentes arquitectónicos. Modelo-Vista-editor fue el primer set." Él ha participado ampliamente en la investigación de métodos orientados a objetos y desarrollado la función de modelado OOram método y herramienta en 1983. Fundó la empresa en 1986 que Taskon herramientas desarrolladas sobre la base de la OORam método. Reenskaug escribió el libro de trabajo con objetos: El Método de Ingeniería de Software OOram con co-autores P. Wold y O. A. Lehne. Más tarde trabajó con el desarrollo de UML. Actualmente [update] es profesor emérito de la informática en la Universidad de Oslo.

2. DEFINICION:

Forma (Patrón de Diseño) que utilizamos los programadores para implementar nuestras aplicaciones, además permite separar nuestra aplicación en un modelo, una vista y con controlador. Este patrón fue introducido por primera vez en el lenguaje “Smalltalk”. [3]

Figura 10.10: Estructura de las clases del MVC

Patrón de diseño de software probado y se sabe que funciona. Con MVC la aplicación se puede desarrollar rápidamente, de forma modular y mantenible. Separar las funciones de la aplicación en modelos, vistas y controladores hace que la aplicación sea muy ligera. Estas características nuevas se añaden fácilmente y las antiguas toman automáticamente una forma nueva. El diseño modular permite a los diseñadores y a los desarrolladores trabajar conjuntamente, así como realizar rápidamente el prototipado. Esta separación también permite hacer cambios en una parte de la aplicación sin que las demás se vean afecdtadas.Aunque lleva algún tiempo acostumbrarse a construir aplicaciones así, estamos seguros de que, una vez construyas tu primera aplicación con CakePHP, no querrás volver a hacerlo de otra forma. [4]

3. FUNDAMENTOS BASICOS ,CAPAS O ETAPAS:

3.1. MODELO: Representación especifica de la información con la cual el sistema opera. La lógica de datos asegura la integridad de estos y permite derivar nuevos datos.Es el encargo de administrar la lógica de tu aplicación. Tiene como finalidad servir de abstracción de algún proceso en el mundo real, además tiene acceso a nuestra Base de Datos, agregando q tiene las funciones que controlan la integridad del sistema.La capa de Modelo comprende los objetos de negocio (típicamente representan objetos almacenados en nuestras fuentes de datos), la lógica de negocio y los accesos a las fuentes de datos (bien sean bases de datos o sistemas de ficheros, por ejemplo). Es la parte que siempre hay que desarrollar de forma diferente, ya que cada aplicación tendrá sus propios objetos y reglas de negocio.

Por esta razón los framework que implementan MVC se suelen complementar con otros frameworks para gestionar los accesos a los datos, como Hibernate o iBATIS. [5]

3.2. VISTA: Presenta el modelo en un formato adecuado para interactuar , usualmente la interfaz del usuario.Sencillamente es la representación visual del modelo. Es la encargada de representar los componentes visuales en la pantalla, Esta asociada a un Modelo, esto le permite que al momento de cambiar el Modelo, la vista redibujara la parta afectada para reflejar los cambios.La capa de Vista, es decir, la capa de presentación es la interfaz con el usuario de la aplicación. Típicamente las aplicaciones web tienen tres tipos de presentación:

las pantallas de información las pantallas en las que un usuario introduce datos las pantallas donde se presentan los resultados solicitados.

Tanto la captación de los datos introducidos como la presentación de los resultados se realiza mediante formularios (implementados en Struts por clases ActionForm).

Para eliminar el código Java en las páginas JSPs y para automatizar tareas, Struts facilita sus taglibs (html, bean y logic). Podemos encontrarnos otras taglibs completamente desarrolladas, o podemos desarrollar nosotros nuestras propias taglibs. [5]

3.3. CONTROLADOR: Este responde a eventos usualmente acciones dl usuario e invoca cambios en el modelo y probablemente en la vista.[6]La capa de Controlador, que controla el flujo (workflow) de la aplicación. Esta capa decide qué acciones se ejecutarán y cuál será la página de destino de estos resultados. Struts nos proporciona la clase ActionServlet que automatiza todo este trabajo y nos permite su configuración (struts-config.xml) de una forma muy sencilla, eligiendo la acción que se ejecutará (implementada por clases Action); esta acción elegirá un destino posible (ActionForward).

Es el escuchador a los eventos que genere el usuario, es decir es el que permite que interactúe el usuario con el sistema. Interpreta los eventos (la entradas) atreves del teclado y/o ratón. [3]

INFOGRAFIA

1. http://www.google.com.co/search? hl=es&q=Trygve+Reenskaug&btnG=Buscar&meta=lr%3Dlang_es

2. http://mundogris.wordpress.com/2008/02/17/mvc-no-es-una- buena-arquitectura-para-la-web/

3. http://inforux.wordpress.com/2008/08/02/modelo-vista- controlador-mvc-para-tus-aplicaciones-java/

4. http://book.cakephp.org/es/complete/10/Understanding-Model- View-Controller

5. http://www.hachisvertas.net/jcs/wiki/index.php? title=Modelo_Vista_Controlador

6. http://www.tufuncion.com/mvc