Universidad Nacional Sede Región Chorotega

Carrera

Ing. en Sistemas de Información

Curso

PROGRAMACIÓN IV

Profesor

Juan Carlos Grijalba

I Semestre

MODELO VISTA CONTROLADOR

Estudiante

Nombre Carne Participación

%

Piedra

Victor

Alcocer

Cubillo

Danny José

Favio

503760490

503830773

50

50

Mayo 7, 2011

Nicoya, Guanacaste, Costa Rica

1

ÍNDICE

INTRODUCCIÓN..................................................................................................................3

Objetivo General:..................................................................................................................4

Objetivos Específicos:...........................................................................................................4

ORIGEN................................................................................................................................5

Modelo..................................................................................................................................5

Características...................................................................................................................6

Vista......................................................................................................................................7

Controlador...........................................................................................................................8

Ventajas de utilizar MVC...................................................................................................9

Desventajas de utilizar MVC.............................................................................................9

DONDE ES UTILIZADO......................................................................................................10

Patrones de Diseños de MVC.............................................................................................11

Variante I.........................................................................................................................11

Variante II........................................................................................................................11

Variante III.......................................................................................................................12

IMPLEMENTACION DEL MVC...........................................................................................12

MVC para aplicaciones Desktop.........................................................................................13

MVC para aplicaciones Web...............................................................................................16

Conclusiones.......................................................................................................................20

Bibliografía..........................................................................................................................21

2

INTRODUCCIÓN

El mercado del software de computadoras personales ha germinado en las

pasadas dos décadas. El procesamiento de texto, la hoja de cálculo, los gráficos

por computadoras, multimedia, entretenimientos, gestión de bases de datos,

aplicaciones financieras, de negocios y personales y redes o acceso a bases de

datos externas son algunas de los cientos de aplicaciones existentes en la

actualidad.

En el mismo período de tiempo mencionado, han aparecido un conjunto de

variantes de solución al diseño y a la arquitectura de las aplicaciones de todo tipo.

No obstante la aplicación de dichas variantes a los software educativos se vuelve

un poco compleja y en ocasiones no compatibles con las características de este

tipo de aplicaciones.

3

Objetivo General:

Explicar el concepto de Modelo Vista Controlador, analizar detalladamente

en qué consiste y dar a conocer la implementación tanto en aplicaciones

web como en aplicaciones de escritorio.

Objetivos Específicos:

Reconocer el concepto de Modelo Vista Controlador y sus

características.

Analizar la estructura del Modelo Vista Controlador y sus tipos.

Identificar las ventajas y desventajas del Modelo Vista Controlador.

Conocer la implementación y sus beneficios del Modelo Vista

Controlador.

4

ORIGEN

EL Modelo Vista Controlador fue descrito por primera vez en 1979 por Trygve

Reenskaug, trabajador de Smalltalk en laboratorios de investigación de Xerox.

En MVC soluciona muchos problemas separando el código en tres aéreas

distintas:

Modelo: que presenta los componentes para el mantenimiento de los datos,

contiene la lógica del negocio.

Vista: que contiene la presentación al usuario.

Controlador: que contiene la lógica que decide que acciones deben ser

tomadas para cada una de las partes del sistema.

Estos tres componentes son los pilares principales del patrón en sí.

ModeloUn modelo se puede ver como una representación abstracta de cómo los datos

son procesados por el sistema. “Los modelos están representados, como un

conjunto de datos y métodos necesarios para procesar estos datos por medio del

encapsulamiento de estos datos y funcionalidades” [3]. Deber ser independiente

de la entrada o salida de datos.

5

Un modelo puede ser dividido en varios sub-modelos pero todos estos sub-

modelos deben ser totalmente compatibles con el principal.

Características:

Se le considera el núcleo de la aplicación.

Lleva a cabo las tareas de la aplicación

Si se presentan cambios significativos en este, se deben actualizar todos los

componentes de la aplicación necesarios.

6

VistaLa vista se encarga de desplegarle la información al usuario de la aplicación por

medio de una interfaz grafica, y obtener los datos del modelo. Es la única parte de

la aplicación que interactúa con el usuario.

Gracias es esta característica de múltiples vistas se pueden existir por ejemplo en

una aplicación una vista para el cliente, una vista del operador, o tener una vista

general del administrador del sistema.

Cada vista tiene asociado un controlador que recibe la entrada de los datos, la

cual debe pasar al modelo para obtener un resultado. Cada vez que el modelo

devuelve algún resultado a la vista, esta se debe actualizar para desplegar la

nueva información en la pantalla.

7

ControladorLos controladores son asociados a las vistas en una relación uno a uno, existen

tantos controladores como vistas en una aplicación.

El contralor toma la entrada proveniente de la vista como un evento, este

despacha estos eventos dependiendo de la funcionalidad que presente el modelo,

traduciendo estos para ser interpretados tanto para la vista como el modelo, esto

se realiza por cada evento notable que se obtenga.

“El comportamiento del controlador es definido por los diferentes estados del

modelo, este registra cualquier cambio que se presente, disparando un proceso

para que se actualice la información” [3].

8

Ventajas de utilizar MVC Claridad en el diseño: facilita en entendimientos del modelo, facilita la

implementación y mantenimiento de la aplicación.

Modularidad: Esta modularidad en el diseño permite a los componentes de la aplicaciones sean flexibles, permitiendo agregar o quitar estos sin afectar a gran medida la aplicación. El desarrollo de los distintos componentes se puede realizar en paralelo, una vez que el interfaz entre los componentes este claramente definida.

Vistas Múltiples: permite mostrar el estado en que se encuentra el modelo de diferentes maneras como por ejemplo los juegos. Permitiendo tener una vista para mostrar el estado del modelo y otra vista que recoge los datos.

Facilidad de crecimientos: esto se da cuando existe versionamientos de la aplicación en donde cada componente se va desarrollando, así mismo se puede presentar cuando se necesitan dos tipos de usuarios para la aplicación: usuario o administrador, en donde existe una variación para cada uno, ya que utilizan el mismo modelo, sin embargo cambia la vista y el controlador.

Distribuible: se puede distribuir cualquier aplicación MVC, en aplicaciones cliente y servidor. En donde físicamente la parte de la vista se ubica en un cliente, mientras que la parte del controlador y el modelo se encuentra ubicado en otra locación, accediendo este por medio de una red.

Desventajas de utilizar MVC

El tiempo de desarrollo de una aplicación que implementa el

patrón de diseño MVC es mayor, al menos en la primera etapa,

que el tiempo de desarrollo de una aplicación que no lo

implementa, ya que MVC requiere que el programador implemente

una mayor cantidad de clases que en un entorno de desarrollo

común no son necesarias. Sin embargo, esta desventaja es muy

relativa ya que posteriormente, en la etapa de mantenimiento de

la aplicación, una aplicación MVC es muchísimo mas mantenible,

extensible y modificable que una aplicación que no lo implementa.

9

MVC requiere la existencia de una arquitectura inicial sobre la que

se deben construir clases e interfaces para modificar y comunicar

los módulos de una aplicación. Esta arquitectura inicial debe

incluir, por lo menos: un mecanismo de eventos para poder

proporcionar las notificaciones que genera el modelo de

aplicación; una clase Modelo, otra clase Vista y una clase

Controlador genéricas que realicen todas las tareas de

comunicación, notificación y actualización que serán luego

transparentes para el desarrollo de la aplicación.

MVC es un patrón de diseño orientado a objetos por lo que su

implementación es sumamente costosa y difícil en lenguajes que

no siguen este paradigma. 498 · Ernesto Bascon: El patrón de

diseño Modelo-Vista-Controlador (MVC)

DONDE ES UTILIZADO

Para el diseño de aplicaciones con sofisticados interfaces se utiliza el patrón de

diseño Modelo-Vista-Controlador. La lógica de un interfaz de usuario cambia con

más frecuencia que los almacenes de datos y la lógica de negocio. Si realizamos

un diseño ofuscado, es decir, un pastiche que mezcle los componentes de interfaz

y de negocio, entonces la consecuencia será que, cuando necesitemos cambiar el

interfaz, tendremos que modificar trabajosamente los componentes de negocio.

Mayor trabajo y más riesgo de error.

Se trata de realizar un diseño que desacople la vista del modelo, con la finalidad

de mejorar la reusabilidad. De esta forma las modificaciones en las vistas

impactan en menor medida en la lógica de negocio o de datos.

10

Patrones de Diseños de MVC

Se han desarrollado a lo largo de los años, desde la presentación de este patrón a

la comunidad científica 3 variantes fundamentales, que se presentan brevemente

a continuación.

Variante I:

Variante en la cual no existe ninguna comunicación entre el Modelo y la Vista y

esta última recibe los datos a mostrar a través del Controlador.

Variante II:

Variante en la cual se desarrolla una comunicación entre el Modelo y la Vista,

donde esta última al mostrar los datos los busca directamente en el Modelo, dada

una indicación del Controlador, disminuyendo el conjunto de responsabilidades de

este último.

11

Variante III:

Variante en la cual se diversifica las funcionalidades del Modelo teniendo en

cuenta las características de las aplicaciones multimedia, donde tienen un gran

peso las medias utilizadas en estas.

IMPLEMENTACION DEL MVC

Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que

sigue el control generalmente es el siguiente:

1. El usuario interactúa con la interfaz de usuario de alguna forma (por

ejemplo, el usuario pulsa un botón, enlace)

2. El controlador recibe (por parte de los objetos de la interfaz-vista) la

notificación de la acción solicitada por el usuario. El controlador gestiona el

evento que llega, frecuentemente a través de un gestor de eventos (handler)

o callback.

3. El controlador accede al modelo, actualizándolo, posiblemente

modificándolo de forma adecuada a la acción solicitada por el usuario. Los

controladores complejos están a menudo estructurados usando un patrón de

comando que encapsula las acciones y simplifica su extensión.

4. El controlador delega a los objetos de la vista la tarea de desplegar la

interfaz de usuario. La vista obtiene sus datos del modelo para generar la

12

interfaz apropiada para el usuario donde se refleja los cambios en el modelo

(si se utiliza la variante 2 descrita anteriormente, de lo contrario lo obtiene a

través del Controlador). El modelo no debe tener conocimiento directo sobre

la vista. Sin embargo, el patrón de observador puede ser utilizado para

proveer cierta indirección entre el modelo y la vista, permitiendo al modelo

notificar a los interesados de cualquier cambio. Un objeto vista puede

registrarse con el modelo y esperar a los cambios, pero aun así el modelo en

sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de

dominio (el modelo) a la vista aunque puede dar la orden a la vista para que

se actualice. Nota: En algunas implementaciones la vista no tiene acceso

directo al modelo, dejando que el controlador envíe los datos del modelo a la

vista, según lo descrito en la segunda variante.

5. La interfaz de usuario espera nuevas interacciones del usuario,

comenzando el ciclo nuevamente.

MVC para aplicaciones Desktop

Figura1 [2]

Como lo muestra la figura 1 este es un típico ejemplo del diagrama del MVC para una aplicación Desktop, en este se muestra la independencia que existente entre cada uno de los componentes que integran el patrón.

Se debe distribuir el controlador y a la vista en la capa de presentación y al modelo en un servidor de contenido.

13

El Modelo lo constituyen los datos y las operaciones de la aplicación a implementar

La Vista despliega la información del modelo en formato correspondiente en este caso una interfaz grafica

El Controlador responde a los eventos de la interfaz y comunica las acciones al modelo.

Ejemplo:

Vista de administrador

Vista de usuario

14

Controlador

Modelo

15

MVC para aplicaciones Web

Figura 2 [4]

Como lo muestra la figura 2 este es ejemplo del diagrama del MVC para una aplicación web, en este se muestra la independencia que existente entre cada uno de los componentes que integran el patrón, así mismo nos muestra los otros

16

componentes que interactúan con el modelo como lo es el clientes web y internet, que es a través de este último es que se puede utilizar la aplicación.

El modelo representa la información con la que trabaja la aplicación, es decir, su lógica de negocio. Se encarga de la abstracción de la lógica relacionada con los datos, haciendo que la vista y las acciones sean independientes, por ejemplo, el tipo de gestor de bases de datos utilizado por la aplicación.

La vista transforma el modelo en una página web que permite al usuario interactuar con ella. En la vista se detallan otros elementos que pueden estar presentes en esta como:

Los elementos que debe tener la vista: Business logic widgets (botones que realizan determinada acción), Navigation widgets que permiten la navegación dentro del sitio, Skin (el color estándar del sitio o presentaciones diferentes de este).

View Technologies.

Plantillas.

Hojas de estilo: separar la estructura de un documento de su presentación siento esta un sitio web y permite un control centralizado de la presentación de un sitio web completo con lo que se agiliza de forma considerable la actualización del mismo.

Uso del patrón Decorator: es un patrón de diseño estructural que nos permite añadir comportamientos nuevos, o adicionales, a un objeto en tiempo de ejecución, dependiendo de la situación.

El controlador se encarga de procesar las interacciones del usuario y realiza los cambios apropiados en el modelo o en la vista. Detalle del controlador:

Trabajo del Contralor:

o Analizar las peticiones del usuario.

o Validar las peticiones de usuario asegurando que estas se ajusta a

los requisitos de aplicación.

o Determinar lo que el usuario está tratando de hacer basados en:

URL, parámetros de la petición o elementos de algún formulario.

o Obtención de datos del modelo.

17

o Seleccionar la siguiente vista que usuario debe ver.

o Permite mantener la navegación en la aplicación.

Tecnologías del Contralor: frameworks que pueden utilizarse para proporcionar la capa de control en la aplicación.

En primer lugar, el código PHP puro con toda la lógica de negocio se incluye en el script del controlador, como se muestra a continuación.

La parte del controlador, en index.php

Código:

El controlador es mucho más fácil de leer. Su única tarea es la de obtener los datos del modelo y pasárselos a la vista y viceversa. En las aplicaciones más complejas, el controlador se encarga además de procesar las peticiones, las sesiones de los usuarios, la autenticación, etc. El uso de nombres apropiados para las funciones del modelo hace que sea innecesario añadir comentarios al código del controlador.

La parte de la vista, en vista.php

18

Código:

Una buena regla general para determinar si la parte de la vista está suficientemente limpia de código es que debería contener una cantidad mínima de código, la suficiente como para que un diseñador HTML sin conocimientos pueda entenderla.

Separando la manipulación de los datos, la parte del modelo, en modelo.php

Código:

El script del modelo solamente se encarga del acceso a los datos y puede ser reorganizado a tal efecto. Todos los parámetros que no dependen de la capa de

19

datos se deben obtener a través del controlador y por tanto, no se puede acceder a ellos directamente desde el modelo. Las funciones del modelo se pueden reutilizar fácilmente en otros controladores.

Conclusiones

La lógica de la interfaz de usuario tiende a cambiar con mayor frecuencia

que la lógica de negocio, especialmente en aplicaciones basadas en Web.

Si el código de la presentación y la lógica de negocios se combinan en un

solo objeto, y se tiene que modificar alguno de estos objetos que contienen

la lógica del negocio cada vez que cambia la interfaz de usuario se vuelve

muy caro.

La independencia en cada una de las capas no permite una mejor

matenibilidad del código de nuestra aplicación.

La aplicación muestra los mismos datos de diferentes maneras. Permite

tener múltiples vistas de los mismos datos se muestran al mismo tiempo. Si

el usuario cambia los datos en una vista, el sistema debe actualizar todas

las vistas de los datos de forma automática.

Una clara separación de la interfaz de usuario y lógica de negocio minimiza

el riesgo de introducir errores en la lógica de negocio.

El MVC permite la reutilización de cada una de sus partes.

20

Nos facilita la estandarización.

El MVC debería de ser el patrón básico a implementarse en cada aplicación

que se desarrolla, tomándolo como una buena práctica de programación.

Bibliografía

El patrón de diseño Modelo-Vista-Controlador (MVC) y su implementación en

Java Swing

http://www.ucbcba.edu.bo/Publicaciones/revistas/actanova/

documentos/v2n4/v2.n4.bascon.pdf) Visitado el 04-06-2011

Patrón "Modelo-Vista-Controlador"

http://www.proactiva-calidad.com/java/patrones/mvc.html Visitado el 04-06-2011

[2] Joseph Bergin. Building Graphical User Interfaces with the MVC pattern.

http://www.csis.pace.edu/%20bergin/mvc/mvcgui.html. Visitado el 03-06-2011

[3] Steve Burbeck. Applications Programming in Smalltalk-80(TM): How to use Mo-

del-View-Controller (MVC).

http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html.

[4] John Deacon. Model-View-Controller (MVC) Architecture.

21

http://www.jdl.co.uk/briefings/mvc.pdf. Visitado el 03-06-2011

22