Las aplicaciones Web basadas en MVC

O. L. Peña Valerio1*
1
Departamento de Ingeniería en Sistemas Computacionales, Instituto Tecnológico Superior de Alvarado,
C.P. 95250, Alvarado Ver., México
*olpenav@itsav.edu.mx
Área de participación: Ingeniería de Software

Resumen
En la actualidad las aplicaciones de software son más complejas y requieren que estén disponibles en
cualquier lugar y en cualquier momento, es decir, de forma distribuidas y abiertas. Por lo que el diseño del
software utilizando cualquiera de sus paradigmas se hace cada vez más difícil de implementar y que decir de la
reutilización del software es aún más dificultoso. Es por ello que la utilización de un patrón de diseño reutilizable
y flexible es necesario para la complejidad actual del desarrollo de software. Si bien se han propuesto diferentes
patrones de diseño arquitectónico para las aplicaciones Web, éste estudio demostró que la aplicación del patrón
MVC (Modelo-Vista-Controlador) mejora la productividad de los desarrolladores mediante la reutilización de
código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y
su posterior mantenimiento.

Palabras clave: MVC, MVP, Framework, Patrón

Abstract
Currently the software applications are more complex and require them to be available anywhere and anytime,
ie, distributed and open manner. As software design using any of their paradigms becomes increasingly more
difficult to implement and to say of software reuse is even more difficult. That is why the use of a pattern of
reusable and flexible design is required for the current complexity of software development. While there have
proposed different architectural design patterns for Web applications, this study demonstrated that the
application of pattern MVC (Model-View-Controller) improves developer productivity by reusing code and the
separation of concepts, features seek to facilitate the task of application development and maintenance.

1. Introducción

La historia de los patrones de software no comienza con un científico de la computación, sino con un arquitecto
constructor, Christopher Alexander, quien reconoció que siempre que se diseñaba un edificio era reconocible un
conjunto de problemas recurrentes. Definió éstos y sus soluciones como patrones, y los describió del modo
siguiente (Pressman R. S., 2010, p. 295, citado en Alexander C., 1977).

Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo
de su solución en forma tal que es posible usarla un millón de veces sin elaborarla dos veces de la misma forma.
A pesar de que Alexander estaba hablando acerca de los patrones en los edificios y ciudades, lo que dice es
cierto acerca de los patrones de diseño orientado a objetos. Nuestras soluciones se expresan en términos de
objetos e interfaces en lugar de paredes y puertas, pero en el centro de ambos tipos de patrones es una
solución a un problema en un contexto. Las ideas de Alexander fueron traducidas por vez primera al mundo del
software en los libros de Gamma (Pressman R. S., 2010, p. 296, citado en Gamma, E., et al, 1995).

En general, un patrón tiene cuatro elementos esenciales (Gamma E., et al, 1995):

1. El nombre del patrón es un manejador (handle) que podemos utilizar para describir un problema de diseño,
sus soluciones, y las consecuencias en una o dos palabras.

1
 2. El problema describe cuándo aplicar el patrón. En él se explica el problema y su contexto. Podría describir
los problemas específicos de diseño tales como la forma de representar algoritmos como objetos. Podría
describir las estructuras de clase o de objetos que son sintomáticos de un diseño inflexible.
3. La solución se describen los elementos que integran el diseño, sus relaciones, responsabilidades y
colaboraciones. La solución no describe un diseño concreto en particular o aplicación, porque un patrón es
como una plantilla que puede ser aplicado en muchas situaciones diferentes. En lugar de ello, el patrón
proporciona una descripción abstracta de un problema de diseño y cómo una disposición general de
elementos (clases y objetos en nuestro caso) resuelve.
4. Las consecuencias son los resultados y compromisos de aplicar el patrón. Dado que la reutilización es a
menudo un factor en el diseño orientado a objetos, las consecuencias de un patrón incluyen su impacto en
la flexibilidad, extensibilidad, o la portabilidad del sistema.

De lo anterior se puede decir que un patrón de diseño se caracteriza como “una regla de tres partes que
expresa una relación entre cierto contexto, un problema y una solución” [Pressman R. S., 2010, p. 296, citado
en Alexander C., 1979]. Para el diseño de software, el contexto permite al lector entender el ambiente en el que
reside el problema y qué solución seria apropiada en dicho ambiente. Un conjunto de requerimientos, incluidas
limitaciones y restricciones, actúan como sistema de fuerzas que influyen en la manera en la que puede
interpretarse el problema en este contexto y en cómo podría aplicarse con eficacia en la solución de
aplicaciones Web de forma distribuidas y abiertas.

En este trabajo se hace énfasis en el patrón MVC (Modelo-Vista-Controlador) como un patrón de arquitectura
de las aplicaciones software que separa la lógica de negocio de la interfaz de usuario, facilitando la evolución
por separado de ambos aspectos e incrementando la reutilización y flexibilidad. Además, se hace mención del
patrón MVP (Modelo-Vista-Presentador) usado también para el diseño de aplicaciones Web junto con los
conceptos relevantes del diseño arquitectónico mediante la separación de intereses y algunos de los marcos de
trabajo basados en MVC de uso en la industria de software. En este trabajo se estudiaron las características de
ambos patrones con la finalidad de establecer un comparativo acorde a un conjunto de rasgos importantes para
la implementación de aplicaciones Web.

2. Introducción a los patrones de diseño

¿Qué son los patrones de software?
Los patrones de software son soluciones reutilizables a los problemas que ocurren durante el desarrollo de un
sistema de software o aplicación. Estos proporcionan un proceso consistente o diseño que uno o más
desarrolladores pueden utilizar para alcanzar sus objetivos. También proporciona una arquitectura uniforme que
permite una fácil expansión, mantenimiento y modificación de una aplicación. (Gamma E., et al, 1995, p. 12)

Buschmann Frank, Meunier Regine, Rohnert Hans, Sornmerlad Peter, Stal Michael. (1996). Afirman que una
mirada más cercana a los patrones existentes revela que cubren diversos rangos de escala y abstracción.
Algunos patrones ayudan en la estructuración de un sistema de software en subsistemas. Otros patrones
apoyan el refinamiento de los subsistemas y componentes, o de las relaciones entre ellos. Otros patrones
ayudan en la implementación de determinados aspectos de diseño en un lenguaje de programación específico.
Los patrones también van desde los domm-independent, tal como estos para desacoplar los componentes que
interactúan, a los patrones que abordan aspectos específicos de dominio, como las políticas de transacción en
las aplicaciones de negocio, o enrutamiento de llamadas en las telecomunicaciones.

Tipos de Patrones
Existen diferentes tipos de patrones. Dependiendo del nivel conceptual de desarrollo donde se apliquen, se
distinguen (de más abstractos a más concretos): patrones de análisis, patrones arquitectónicos, patrones de
diseño y patrones de implementación o idioms.

Dependiendo del propósito funcional del patrón, se distinguen los siguientes tipos:
§ Fundamental: construye bloques de otros patrones.
§ Presentación: Estandariza la visualización de datos.
§ De creación: Creación condicional de objetos.

2
 § Integración: Comunicación con aplicaciones y sistemas y recursos externos.
§ De particionamiento: Organización y separación de la lógica compleja, conceptos y actores en múltiples
clases.
§ Estructural: Separa presentación, estructuras de datos, lógica de negocio y procesamiento de eventos
en bloques funcionales.
§ De comportamiento: Coordina/Organiza el estado de los objetos.
§ De concurrencia: Maneja el acceso concurrente de recursos.

El patrón Modelo-Vista-Controlador (MVC) es un ejemplo de patrón arquitectónico estructural.

3. Patrón de Diseño MVC (Modelo-Vista-Controlador)

Introducción
Las aplicaciones Web pueden desarrollarse utilizando cualquier arquitectura posibles. La arquitectura del patrón
Modelo-Vista-Controlador es un paradigma de programación bien conocido para el desarrollo de aplicaciones
con interfaz gráfica (GUI).

Características del MVC

El patrón de diseño MVC (Modelo-Vista-Controlador) es para el sistema que presenta varias vistas de los
mismos datos. Separa la capa de los datos y la capa de expresión, y divide los objetos del sistema en tres
clases: la clase Modelo, la clase Vista y la clase de control. La clase Modelo implementa la lógica de negocio y
datos; La clase Vista implementa la lógica de visualización, y la clase de Controlador implementa el
procesamiento de control. MVC mantiene a los tres tipos de lógica de independencia para construir la lógica de
negocio orientada a los negocios y los datos y el diseño de la lógica de control y visualización de aplicaciones
orientadas. El cambio de los procesos de negocio no modifica la lógica de negocio y datos. El cambio de los
principios de negocio y algoritmos sólo modifica la clase Modelo. Así MVC separa el acceso de los datos y la
visualización y garantizar la independencia módulos. En la figura 1 se muestra el Framework del MVC. (Hao
Liancai, 2013, p.36)

Figura 1. MVC Models Frameworks

Sleidy Fernández Romero y Yanette Díaz González (2012) ilustran los elementos del patrón y la interrelación
entre estos. Ver figura 2.

3
 Figura 2. Interrelación entre los elementos del patrón MCV

Modelos del MVC

En programación de aplicaciones en Smalltalk-80: Cómo utilizar Model-View-Controller (MVC) (MSDN Library
Model-View-Controller, 2015 citado en Burbeck Steve, 1992], Steve Burbeck describe dos variaciones de MVC:
un modelo pasivo y un modelo activo.

El modelo pasivo cuando se emplea un controlador manipula el modelo exclusivamente. El controlador modifica
el modelo y luego informa a la opinión de que el modelo ha cambiado y debe ser renovado (ver Figura 3). El
modelo en este escenario es completamente independiente de la vista y el controlador, lo que significa que no
hay medios para el modelo para informar de los cambios en su estado. El protocolo HTTP es un ejemplo de
esto. No hay manera simple en el navegador para obtener actualizaciones asíncronas desde el servidor. El
navegador muestra la vista y responde a la entrada del usuario, pero no detecta los cambios en los datos en el
servidor. Sólo cuando el usuario solicita explícitamente una renovación es el servidor interrogado por los
cambios.

Figura 3. Comportamiento del modelo pasivo

El modelo activo se utiliza cuando el modelo cambia de estado sin la participación de la controladora. Esto
puede suceder cuando otras fuentes están cambiando los datos y los cambios deben reflejarse en las vistas. El
patrón Observer proporciona un mecanismo para alertar a otros objetos de los cambios de estado sin introducir
dependencias en ellos. La Figura 4 muestra la estructura de la MVC activo utilizando observador y cómo el
observador aísla el modelo de referencia directamente vistas.

Figura 4. Comportamiento del modelo activo

4
MVC y Java EE
En el Las aplicaciones de MVC pueden ser implementadas con Java EE utilizando JSP para las vistas, servlets
como controladores y JDBC para el modelo. Ver Figura 5.

Figura 5. Implementación MVC en Java EE

• El Controlador (Controller)
o Servlet central recibe peticiones, procesa URL recibida y delega procesamiento a JavaBeans
o Servlet guarda resultado de procesamiento realizado por JavaBeans en el contexto de la petición, la
sesión o la aplicación
o Servlet transfiere control a un JSP que lleva a cabo la presentación de resultados
• El Modelo (Model)
o JavaBeans (o EJBs para aplicaciones más escalables) desempeña el rol de modelo:
o Algunos beans ejecutan lógica
o Otros guardan datos
o Normalmente:
o Servlet controlador invoca un método en bean lógico y éste devuelve un bean de datos
o Autor de JSP tiene acceso a bean de datos
• La Vista (View)
o Rol ejecutado por JSPs
o Servlet Controlador transfiere control al JSP después de haber guardado en un contexto el resultado
en forma de un bean de datos
o JSP usa jsp:useBean y jsp:getProperty para recuperar datos y formatear respuesta en HTML o XML.
(Jendrock et al., 2014)

4. Patrón de Diseño MVP (Modelo-Vista-Presentador)

Introducción
El patrón Model View Presenter (MVP) fue descrita por primera vez por Mike Potel de Taligent IBM (1996), el
cual es un modelo de programación de última generación para el C ++ y lenguajes de programación Java,
basado en una generalización del modelo de programación MVC clásico de Smalltalk. Potel en su obra sobre
MVP pone en duda la necesidad de que la clase Controller en MVC. Se dio cuenta de que modernas interfaces
de usuario del sistema operativo ya proporcionan la mayor parte de la funcionalidad del controlador de la clase
Vista y por lo tanto el controlador parece un poco redundante.

Potel Mike (1996) en su trabajo analiza los tipos de interacciones que la Vista puede tener con el Modelo.
Clasificó las acciones del usuario como selección, ejecución de comandos, y eventos de recaudación. Él, por lo
tanto, define las clases de selección y de comando que, como el nombre sugiere, se puede seleccionar una
subsección del modelo y la elaboración de operaciones, y también introdujo la clase Interactor que encapsula
los eventos que cambian los datos. La nueva clase llamada el Presentador encapsula la Selección, Comando e
Interador.

Como se ha visto, la relación modelo-vista es indirecta basada en el patrón de diseño Observer. El modelo
puede notificar a la vista de que los nuevos datos han llegado, y la vista puede actualizar sus datos del modelo
que está suscrito.

5
Descripción del MVP
MVP ofrece un potente y fácil entendimiento de la metodología de diseño para una amplia gama de tareas de
aplicación y desarrollo de componentes. Añade un gran valor a los programas para desarrolladores que
emplean MVP. MVP también es adaptable a través de múltiples arquitecturas cliente/servidor y aplicaciones de
varios niveles.

La idea básica fue "girando MVC" de una manera donde la Vista absorbe la funcionalidad del controlador y la
nueva clase (el presentador), se añade. El presentador puede acceder a la vista y el modelo directamente, y la
relación modelo-vista todavía puede existir en su caso. En general, la Vista despliega los datos y el presentador
puede actualizar el modelo y la vista directa. Ver la Figura 6.

Figura 6. El Modelo Vista Presentador

Si añadimos Interactor, selección y clases de comandos, vamos a obtener el cuadro completo. Hay diferentes
favores de MVP, como hemos visto, el presentador puede acceder a la Vista directamente, o la relación Modelo-
Vista basado en el patrón Observador todavía puede existir. Como se muestra en la figura 7.

Figura 7. MVP

Boodhoo Jean-Paul (2006) menciona como las tecnologías de interfaz de usuario de creación como formularios
ASP.NET y Windows® son cada vez más poderosa, es una práctica común para que la capa de interfaz de
usuario haga más de lo que debería. Sin una clara separación de responsabilidades, la capa de interfaz de
usuario a menudo puede llegar a ser como un buzón de correo para la lógica que realmente pertenece a otras
capas de la aplicación.

En resumen, las tres preguntas de gestión de datos, y las tres preguntas de la interfaz de usuario, comprenden
las seis preguntas que un desarrollador da respuestas en la creación de un programa basado en MVP completo,
como se muestra en la figura 8.

Figura 8. Preguntas gestión de datos e interfaz de usuario.

6
A continuación en la figura 9 se muestra un diagrama de clases para el modelo de programación MVP que
revela la correspondencia directa de la estructura de clases y los conceptos que se han estado discutiendo.

Figura 9. Diagrama de clase MVP

5. Marco de trabajo basados en MVC

Aunque originalmente MVC fue desarrollado para aplicaciones de escritorio, ha sido ampliamente adaptado
como arquitectura para diseñar e implementar aplicaciones web en los principales lenguajes de programación.
Se han desarrollado multitud de frameworks, comerciales y no comerciales, que implementan este patrón; estos
frameworks se diferencian básicamente en la interpretación de como las funciones MVC se dividen entre cliente
y servidor.

Los primeros frameworks MVC para desarrollo web planteaban un enfoque de cliente ligero en el que casi todas
las funciones, tanto de la vista, el modelo y el controlador recaían en el servidor. En este enfoque, el cliente
manda la petición de cualquier hiperenlace o formulario al controlador y después recibe de la vista una página
completa y actualizada (u otro documento); tanto el modelo como el controlador (y buena parte de la vista)
están completamente alojados en el servidor. Como las tecnologías web han madurado, ahora existen
frameworks como JavaScriptMVC, Backbone o jQuery14 que permiten que ciertos componentes MVC se
ejecuten parcial o totalmente en el cliente. (Wikipedia, 2015, p. 1)

Spring MVC
El marco (MVC) modelo-vista-controlador Spring Web está diseñado en torno a un DispatcherServlet que envía
solicitudes a los manipuladores, con asignaciones de controlador configurable, vista resolución, localidad, zona
horaria y la resolución de tema, así como apoyo para la carga de archivos. El controlador predeterminado se
basa en @Controller y anotaciones @RequestMapping, ofreciendo una amplia gama de métodos de
manipulación flexibles. Con la introducción de Spring 3.0, el mecanismo @Controller también le permite crear
sitios Web RESTful y aplicaciones, a través de la anotación @PathVariable y otras características. (Johnson
Rob et al., 2014).

7
6. Resultados y discusión
Como resultado del presente trabajo, se procedió a realizar un análisis comparativo entre el MVC (Modelo-
Vista-controlador) y el MVP (Modelo-Vista-Presentador) cuyos resultados fueron plasmados en la Tabla 1.
Modelo Vista Controlador (MVC)10
Modelo: datos y reglas de negocio.
Vista: muestra la información del modelo al usuario.
Controlador: gestiona las entradas del usuario.
Elementos
del patrón
Separación clara entre los componentes de un
programa; lo cual permite su implementación por
separado.
Interfaz de Programación de Aplicaciones API
(Aplication Programming Interface) muy bien
Ventajas definida; cualquiera que use el API, podrá́
reemplazar el Modelo, la Vista o el Controlador, sin
aparente dificultad.
Conexión entre el Modelo y sus Vistas dinámica; se
produce en tiempo de ejecución, no en tiempo de
compilación.
Complejidad. El patrón MVC introduce nuevos
niveles de indirección y por lo tanto aumenta la
complejidad de la solución ligeramente. También
aumenta la naturaleza orientada a eventos del
código de interfaz de usuario, que puede ser más
Desventajas
difícil de depurar.
Costo de actualizaciones frecuentes. Disociar el
modelo de la vista no significa que los
desarrolladores del modelo pueden ignorar la
naturaleza de las visitas.
La idea fundamental de MVC es una separación de
la lógica de dominio y la interfaz gráfica de objetos
en el Modelo y la Vista. Estos dos están
relacionados indirectamente por el uso del
mecanismo de Publicación-Suscripción conocido
Distinción como el patrón Observer. Otro elemento de este
principal diseño es un Controlador que implementa una
entre estrategia particular para la vista.
modelos
8
Modelo Vista Presentador (MVP)
El modelo: Que es donde se lleva a cabo toda la
lógica de negocio.
La vista: Compuesta de las ventanas y controles
que forman la interfaz de usuario de la
aplicación.
El presentador. Escucha los eventos que se
producen en la vista y ejecuta las acciones
necesarias a través del modelo. Además puede
tener acceso a las vistas a través de las interfaces
que la vista debe implementar.
La distinción Modelo/Vista trae el beneficio de la
Independencia de la Vista.
La distinción Selección/Modelo proporciona el
beneficio de la Independencia del Modelo.
La distinción Comando/Selección proporciona el
beneficio de reutilización de Comando.
El presentador puede acceder a la vista
directamente.
La distinción clave es que MVP separa
verdaderamente la interfaz de usuario de la capa
de dominio/servicio de la aplicación.
La complejidad del modelo no está el poder de
MVP, está en la mantenibilidad del código y en el
nivel de desacoplamiento que se puede llegar a
lograr entre tecnología de interfaz de usuario y la
lógica de la aplicación.
La idea básica es que la clase Presenter haga de
intermediario entre la Vista (la interfaz gráfica de
usuario) y el modelo de datos. El MVP delega
más trabajo a la Vista y elimina el controlador.
Introduce la clase Presentador que encapsula el
estado y comandos de la Vista. El Presentador
puede acceder a la vista directamente. El
Modelo-Vista relación basada en el patrón
Observador todavía existe en MVP; Sin embargo,
el Presentador puede acceder a la vista
directamente. Aunque esto es fácil de usar e
implementar, los desarrolladores deben tener
cuidado de no romper la lógica del sistema que
están tratando de modelar.
 Modelo Vista Controlador (MVC)10 Modelo Vista Presentador (MVP)
Tecnología .NET y Java .NET y Java
de elección
Para el diseño de aplicaciones con interfaces Se puede utilizar para crear aplicaciones
complejas. La lógica de una interfaz de usuario independientes, cada vez más software de hoy
cambia con más frecuencia que los almacenes de involucra componentes que crean, o unidades de
Problema datos y la lógica de negocio. Se trata de realizar un
programas más pequeños que se pueden
que se está diseño que desacople la vista del modelo, con la combinar para trabajar juntos para crear
tratando de finalidad de mejorar la reusabilidad de las partes.aplicaciones completas. En este caso, el modelo
resolver de MVP descansa sobre una arquitectura de
componentes, por lo que los modelos, vistas y
eventos se correlacionan con un tiempo de
ejecución de componente subyacente.
Tabla 1. Comparativa entre el MVC y el MVP

Trabajo a futuro

Desarrollar un ejemplo paso a paso en donde se implemente el MVC utilizando Java EE.

Conclusiones
Con este trabajo se pudo demostrar la aplicación de los patrones de diseño y en especial los patrones
arquitectónicos estructurales Modelo-Vista-Controlador (MVC) y Modelo-Vista-Presentador (MVP) en el
desarrollo de aplicaciones Web. En cuanto a la información hubo más acerca del MVC ya que este es el más
utilizado por los desarrolladores en la actualidad.

Se determinó los parámetros Elementos del patrón, Ventajas, Desventajas, Distinción principal entre modelos,
Tecnología de elección, Problema que se está tratando de resolver para la comparación entre los patrones MVC
y MVP para conocer los rasgos más importantes de cada uno de ellos.

En general, se puede decir que el patrón Modelo-Vista-Presentador es una mejora del patrón Modelo-Vista-
Controlador (MVC) basado en tres características:

§ La vista no conoce el modelo.

§ El presentador es independiente de la tecnología de interfaz de usuario.
§ La vista y el presentador son testeables puesto que esta basada en un contrato.

9
Referencias
1. Boodhoo Jean-Paul. Design Patterns: Model View Presenter. Thr Microsoft Journal for Developers MSDN
Magazine. August 2006. Recuperado de https://msdn.microsoft.com/en-us/magazine/cc135440.aspx
2. Buschmann Frank, Meunier Regine, Rohnert Hans, Sornmerlad Peter, Stal Michael. (1996). Pattern-
Oriented Software Architecture Volumen 1: A System of Patterns [Arquitectura de Software Orientada a
Patrones Volumen 1: Un Sistema de patrones]. Chichester England: Wiley.
3. Gamma Erich, Helm Richard, Jhonson Ralph y Vlissides John (1995). Design patterns: elements of reusable
object-oriented software [Los patrones de diseño: Elementos de software orientado a objetos reutilizable].
Boston: Addison-Wesley.
4. Hao Liancai. (2013). Application of MVC Platform in Bank E-CRM [Aplicación de la Plataforma MVC en un
Banco E-CRM]. International Journal of u- and e- Service, Science and Technology, 2(6), 33-42.
Recuperado de EBSCO Publishing.
5. Jendrock et al., (2014). Java Platform, Enterprise Edition The Java EE Tutorial
(Release 7) [Plataforma
Java, Edición Empresarial El tutorial Java EE (Liberación 7)]. 
United State: Oracle.
6. Johnson Rob et al. (2014). Spring Framework Reference Documentation [Documentación de la Referencia
del marco de trabajo Spring]. Liberación 4.1.5. Recuperado de
http://docs.spring.io/spring/docs/current/spring-framework-reference/pdf/spring-framework-reference.pdf
7. MSDN Library. ¿Qué es un patrón de diseño? Por Nicolás Tedeschi. (2015). Recuperado de
https://msdn.microsoft.com/es-es/library/bb972240.aspx#authorbrief
8. MSDN Library. Model-View-Controller. (2015). Recuperado de https://msdn.microsoft.com/en-
us/library/ff649643.aspx
9. Potel Mike. (1996). MVP: Model-View-Presenter The Taligent Programming Model for C++ and Java.
Recuperado de http://www.wildcrest.com/Potel/Portfolio/mvp.pdf
10. Pressman Roger S. (2010). Ingeniería del software un enfoque práctico (Víctor Campos Olguín y Javier
Enríquez Brito trad.). (7ª Ed.). México: Mcgraw-HILL. (Obra original publicada en 2010).
11. Shelest Alexy. (2009). Model View Controller, Model View Presenter, and Model View ViewModel Design
Patterns. Code Project. Recuperado de http://www.codeproject.com/Articles/42830/Model-View-Controller-
Model-View-Presenter-and-Mod
12. Yenisleidy Fernández Romero y Yanette Díaz González. (2012). Patrón Modelo-Vista-Controlador. Revista
Telem@tica. 1(11). 47-57. Recuperado de
http://revistatelematica.cujae.edu.cu/index.php/tele/article/viewFile/15/10
13. Wikipedia La enciclopedia libre. Modelo–vista–controlador. Recuperada de
http://es.wikipedia.org/wiki/Modelo–vista–controlador#Frameworks_MVC

10