REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA DEFENSA

UNIVERSIDAD NACIONAL EXPERIMENTAL POLITÉCNICA
DE LA FUERZA ARMADA NACIONAL
NUCLEO APURE

Modelo
Vista

Controlador

Enero 2021

DESARROLLO
1. ¿Qué es el MVC (Model/View/Controller)?

En líneas generales, MVC es una propuesta de arquitectura del software utilizada para
separar el código por sus distintas responsabilidades, manteniendo distintas capas que se
encargan de hacer una tarea muy concreta, lo que ofrece beneficios diversos.
 MVC se usa inicialmente en sistemas donde se requiere el uso de interfaces de usuario,
aunque en la práctica el mismo patrón de arquitectura se puede utilizar para distintos tipos
de aplicaciones. Surge de la necesidad de crear software más robusto con un ciclo de vida
más adecuado, donde se potencie la facilidad de mantenimiento, reutilización del código y
la separación de conceptos.

2. Orígenes del patrón Modelo-Vista-Controlador

A través de la historia de la informática, es posible afirmar que el patrón

Modelo/Vista/Controlador o MVC (Model/View/Controller) fue descrito por primera vez
en 1979 por Trygve Reenskaug e introducido como parte de la versión Smalltalk-80 del
lenguaje de programación Smalltalk. Fue diseñado para reducir el esfuerzo de
programación necesario en la implementación de sistemas múltiples y sincronizados de los
mismos datos. Sus características principales están dadas por el hecho de que, el Modelo,
las Vistas y los Controladores se tratan como entidades separadas; esto hace que cualquier
cambio producido en el Modelo se refleje automáticamente en cada una de las Vistas.

Este modelo de arquitectura se puede emplear en sistemas de representación gráfica de

datos, donde se presentan partes del diseño con diferente escala de aumento, en ventanas
separadas. Este modelo de arquitectura presenta varias ventajas:

• 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 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.

Al incorporar el modelo de arquitectura MVC a un diseño, las piezas de un programa se

pueden construir por separado y luego unirlas en tiempo de ejecución. Si uno de los
componentes, posteriormente, se observa que funciona mal, puede reemplazarse sin que las
otras piezas se vean afectadas. Este escenario contrasta con la aproximación monolítica
típica de muchos programas de pequeña y mediana complejidad. Todos tienen un Frame
que contiene todos los elementos, un controlador de eventos, un montón de cálculos y la
presentación del resultado. Ante esta perspectiva, hacer un cambio aquí no es nada trivial.

3. Utilidad del patrón.

El patrón de diseño Modelo-Vista-Controlador se utiliza para el diseño de aplicaciones

con interfaces complejas. La lógica de una interfaz de usuario cambia con más frecuencia
que los almacenes de datos y la lógica de negocio. Se trata de realizar un diseño que
desacople la vista del modelo, con la finalidad de mejorar la reusabilidad de las partes.

De esta forma las modificaciones en las vistas impactan en menor medida en la lógica de
negocio o de datos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la
vista es la página HTML y el código que provee de datos dinámicos a la página; el modelo
es el Sistema de Gestión de Bases de Datos y la Lógica de negocio; y el controlador es el
responsable de recibir los eventos de entrada desde la vista. Una de las dificultades con las
que debe lidiar la implementación del patrón es el hecho de que es posible incorporar en las
clases de la vista gran parte o todo el procesamiento de eventos. Con lo que el controlador
puede quedar semioculto dentro de la vista

4. Elementos del patrón Modelo-Vista-Controlador

 Modelo: Datos y reglas de negocio. Es la capa donde se trabaja con los datos, por tanto
contendrá mecanismos para acceder a la información y también para actualizar su
estado. Los datos los tendremos habitualmente en una base de datos, por lo que en los
modelos tendremos todas las funciones que accederán a las tablas y harán los
correspondientes selects, updates, inserts, etc. No obstante, cabe mencionar que cuando
se trabaja con MCV lo habitual también es utilizar otras librerías como PDO o algún
ORM como Doctrine, que nos permiten trabajar con abstracción de bases de datos y
persistencia en objetos. Por ello, en vez de usar directamente sentencias SQL, que
suelen depender del motor de base de datos con el que se esté trabajando, se utiliza un
dialecto de acceso a datos basado en clases y objetos.
 Vista: Muestra la información del modelo al usuario. Las vistas, como su nombre nos
hace entender, contienen el código de nuestra aplicación que va a producir la
visualización de las interfaces de usuario, o sea, el código que nos permitirá renderizar
 los estados de nuestra aplicación en HTML. En las vistas nada más tenemos los códigos
HTML y PHP que nos permite mostrar la salida. En la vista generalmente trabajamos
con los datos, sin embargo, no se realiza un acceso directo a éstos. Las vistas requerirán
los datos a los modelos y ellas se generará la salida, tal como nuestra aplicación
requiera.
 Controlador: Gestiona las entradas del usuario. Contiene el código necesario para
responder a las acciones que se solicitan en la aplicación, como visualizar un elemento,
realizar una compra, una búsqueda de información, etc. En realidad es una capa que
sirve de enlace entre las vistas y los modelos, respondiendo a los mecanismos que
puedan requerirse para implementar las necesidades de nuestra aplicación. Sin embargo,
su responsabilidad no es manipular directamente datos, ni mostrar ningún tipo de salida,
sino servir de enlace entre los modelos y las vistas para implementar las diversas
necesidades del desarrollo.

5. Arquitectura o Función de Aplicación MVC

Usuario

En esta imagen se ha representado con flechas los modos de colaboración entre los
distintos elementos que formarían una aplicación MVC, junto con el usuario. Como se
puede ver, los controladores, con su lógica de negocio, hacen de puente entre los modelos y
las vistas. Pero además en algunos casos los modelos pueden enviar datos a las vistas.

Pasos para el flujo de trabajo característico en un esquema MVC.

  El usuario realiza una solicitud a nuestro sitio web. Generalmente estará
desencadenada por acceder a una página de nuestro sitio. Esa solicitud le llega al
controlador.
 El controlador comunica tanto con modelos como con vistas. A los modelos les
solicita datos o les manda realizar actualizaciones de los datos. A las vistas les solicita
la salida correspondiente, una vez se hayan realizado las operaciones pertinentes
según la lógica del negocio.
 Para producir la salida, en ocasiones las vistas pueden solicitar más información a los
modelos. En ocasiones, el controlador será el responsable de solicitar todos los datos a
los modelos y de enviarlos a las vistas, haciendo de puente entre unos y otros. Sería
corriente tanto una cosa como la otra, todo depende de nuestra implementación; por
eso esa flecha la hemos coloreado de otro color.
 Las vistas envían al usuario la salida. Aunque en ocasiones esa salida puede ir de
vuelta al controlador y sería éste el que hace el envío al cliente, por eso he puesto la
flecha en otro color.

6. Lógica de negocio o Lógica de la aplicación

Hay un concepto que se usa mucho cuando se explica el MVC que es la "lógica de
negocio". Es un conjunto de reglas que se siguen en el software para reaccionar ante
distintas situaciones. En una aplicación el usuario se comunica con el sistema por medio de
una interfaz, pero cuando acciona esa interfaz para realizar acciones con el programa, se
ejecutan una serie de procesos que se conocen como la lógica del negocio. Este es un
concepto de desarrollo de software en general.

La lógica del negocio, aparte de marcar un comportamiento cuando ocurren cosas dentro
de un software, también tiene normas sobre lo que se puede hacer y lo que no se puede
hacer. Eso también se conoce como reglas del negocio. Bien, pues en el MVC la lógica del
negocio queda del lado de los modelos. Ellos son los que deben saber cómo operar en
diversas situaciones y las cosas que pueden permitir que ocurran en el proceso de ejecución
de una aplicación.
 Por ejemplo, Al pensar en un sistema que implementa usuarios. Los usuarios pueden
realizar comentarios. Pues si en un modelo nos piden eliminar un usuario se debe borrar
todos los comentarios que ha realizado ese usuario también. Eso es una responsabilidad del
modelo y forma parte de lo que se llama la lógica del negocio.

Si no queremos que esos comentarios se pierdan otra posibilidad sería mantener

el registro del usuario en la tabla de usuario y únicamente borrar sus datos
personales. Cambiaríamos el nombre del usuario por algo como "Jon Nadie" (o
cualquier otra cosa), de modo que no perdamos la integridad referencial de la
base de datos entre la tabla de comentario y la tabla de usuario (no debe haber
comentarios con un id_usuario que luego no existe en la tabla de usuario). Esta
otra lógica también forma parte de lo que se denomina lógica del negocio y se
tiene que implementar en el modelo.

Incluso, en nuestra aplicación podría haber usuarios especiales, por ejemplo

"administradores" y que no está permitido borrar, hasta que no les quitemos el rol de
administrador. Eso también lo deberían controlar los modelos, realizando las
comprobaciones necesarias antes de borrar efectivamente el usuario.

Sin embargo existe otro concepto que se usa en la terminología del MVC que es la
"lógica de aplicación", que es algo que pertenece a los controladores. Por ejemplo, cuando
me piden ver el resumen de datos de un usuario. Esa acción le llega al controlador, que
tendrá que acceder al modelo del usuario para pedir sus datos. Luego llamará a la vista
apropiada para poder mostrar esos datos del usuario. Si en el resumen del usuario queremos
mostrar los artículos que ha publicado dentro de la aplicación, quizás el controlador tendrá
que llamar al modelo de artículos, pedirle todos los publicados por ese usuario y con ese
listado de artículos invocar a la vista correspondiente para mostrarlos. Todo ese conjunto de
acciones que se realizan invocando métodos de los modelos y mandando datos a las vistas
forman parte de la lógica de la aplicación.

Este concepto Lógica de aplicación no está tan extendido entre todos los teóricos,
pero nos puede ayudar a comprender dónde está cada responsabilidad de nuestro
sistema y dónde tenemos que escribir cada parte del código.
7. Ventajas del MVC
 Desarrollar una aplicación siguiendo este patrón de diseño tiene muchas ventajas:
 La aplicación está implementada modularmente.
 Sus vistas muestran información actualizada siempre.
 El programador no debe preocuparse de solicitar que las vistas se actualicen, ya que
este proceso es realizado automáticamente por el modelo de la aplicación.
 Si se desea hacer una modificación al modelo del dominio, como aumentar métodos o
datos contenidos, sólo debe modificarse el modelo y las interfaces del mismo con las
vistas, no todo el mecanismo de comunicación y de actualización entre modelos.
 Las modificaciones a las vistas no afectan en absoluto a los otros módulos de la
aplicación. MVC es bastante utilizado en la actualidad en marcos de aplicación
orientados a objeto desarrollados para construir aplicaciones de gran tamaño; Java
Swing, Apache Struts, Microsoft ASP.NET, las transformaciones XSL o incluso los
documentos LATEX siguen este patrón de diseño.
 MVC está demostrando ser un patrón de diseño bien elaborado pues las aplicaciones
que lo implementan presentan una extensibilidad y una mantenibilidad únicas
comparadas con otras aplicaciones basadas en otros patrones.

8. Desventajas del 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 más mantenible, extensible y modificable que una aplicación
que no lo implementa.
 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.
9. MVC en Java Swing

Java es un lenguaje orientado a objetos desarrollado por Sun Microsystems que tiene
como características fundamentales su portabilidad a un gran número de plataformas (Java
es en sí una plataforma), su simplicidad y su extenso conjunto de librerías. La librería de
interfaces graficas de usuario que viene en el SDK5 de Java se llama Java Swing y tiene
estas características sobresalientes: Implementa bastantes componentes visuales (botones,
campos de texto, tablas, barras de menús, ´arboles, etc.). Los componentes provistos por
Java Swing son independientes de la plataforma donde se ejecuta la aplicación (contrario a
la idea de AWT , otra librería de interfaces de usuario de Java, que utiliza componentes
nativos de la interfaz de usuario del sistema operativo donde se ejecuta la aplicación) y por
tanto, la portabilidad de las aplicaciones desarrolladas con Swing está garantizada. Permite
“conectar” y “desconectar” estilos de interfaz de usuario (llamados “look and feels”) que
modifican la forma en que se muestra y se comporta toda la interfaz de usuario, así, la
misma aplicación puede verse como una aplicación Windows o como una aplicación
Motif7 simplemente conmutando el look and feels en tiempo de ejecución. Cumple con el
diseño de JavaBeans que hace que los componentes de esta librería puedan ser utilizados en
entornos de desarrollo integrados (IDEs) como JBuilder, Sun Forte for Java o Eclipse. Su
arquitectura está profundamente basada en MVC, lo que proporciona un alto grado de
extensibilidad y de personalización de los componentes de la librería

10. Arquitectura de Java Swing

Si bien Swing se basa en el patrón de diseño MVC, presenta algunas diferencias en su

implementación: La diferencia más notoria es que el controlador y la vista están
implementados como un único elemento denominado “delegado de interfaz de usuario”
(“UI delegate”). Cada componente está asociado a un conjunto de datos (modelo del
dominio) a través de un modelo de aplicación y del delegado de interfaz. Este delegado ha
sido diseñado debido a la incapacidad de programar un controlador genérico con
conocimiento de la vista a la que hubiera podido controlar, por tanto, cada componente
tiene asociado un delegado de interfaz que a su vez, está asociado a un modelo de
aplicación que proporciona toda la información que el delegado requiere y que notifica al
componente si algún cambio se ha dado en el modelo del dominio; por tanto, Java Swing
implementa el modelo MVC en una implementación por componente.

Los modelos implementados en Swing están clasificados en dos categorías: Modelos de

estado de interfaz de usuario y modelos de datos. Los modelos de estado de interfaz definen
el estado visual de un componente, como por ejemplo, el estado de un botón está
presionado o información de los ítems seleccionados en determinada lista. Los modelos de
datos representan información que está contextualizada en la aplicación. Estos modelos de
datos sirven como puente de comunicación entre el modelo del dominio y el delegado de
interfaz de un componente.

11. Ventajas de Java swing

La implementación del patrón MVC en la Liberia Java Swing presenta muchas ventajas:

 Permite la creación de interfaces de usuario de una manera sencilla y rápida,

permitiendo el manejo del patrón MVC pero ocultando los detalles de su
implementación.
 El mecanismo de eventos de Java se adapta perfectamente al mecanismo de
notificaciones de MVC.
 Al estar los modelos separados de la vista, las posibilidades de extensión de la
librería y de personalización de componentes ya existentes son enormes.
12. Desventajas de Java Swing
 La principal desventaja de esta implementación es que, aunque la arquitectura de
Java Swing lo permite, la personalización y extensión de los modelos de algunos
componentes (especialmente tablas y ´arboles), es bastante dificultosa.
 Los modelos de estado y los modelos de datos de Java Swing no están claramente
diferenciados en la implementación y, si bien el modelo de datos es la
implementación del modelo de la aplicación, el modelo de estado está muy alejado
de la definición de modelo que MVC introdujo.
  El controlador definido por MVC es casi inexistente en Java Swing y su trabajo
puede confundirse con el del administrador de interfaz de usuario.
13. Ejemplo Práctico de la Aplicación MVC en Java con netbeans

 Crea un nuevo proyecto en netbeans, para este ejemplo, el proyecto se llama

"jc_mvc_demo". Crea una estructura de paquetes (Controller, Model, View),
hacemos esto para separar cada componente, ser más organizados. Debes tener algo
como esto.

Como puedes observar, mantenemos el paquete default junto al Main.java que nos crea
netbeans, este main es el que nos servirá como nuestro index.php de nuestra aplicación,
nuestro "lanzador".
  Empecemos creando la lógica de la aplicación, crea una nueva clase en el paquete
Model, llámalo "modelo.java" y añade el siguiente código:

Como vemos, nuestra modelo es sencillo, es nada más que la suma de dos valores enteros,
con sus respectivos métodos.

 Diseñemos ahora la interfaz de usuario

Nuestra VISTA. Añade un JFrame al paquete VIEW, llámalo "vista.java", OJO los
recuadros marcados con rojo, son los componentes que tendrán interacción con el modelo,
así que para evitar confusiones, es mejor renombrarlos, coloca los nombres tal como se ven
en la imagen de abajo.
 Netbeans, al añadir objetos a nuestro JFrame, automáticamente los coloca como
“PRIVATE”, debemos cambiar esto, para ello selecciona el objeto "vtxt1" y ve a sus
propiedades, en la pestaña CODIGO, elige el campo “MODIFICADORES DE
VARIABLE“, en la ventana que sale, cambia el atributo PRIVATE, por PUBLIC y dale a
aceptar. Repite esta acción para todos los objetos que están marcados con rojo en la imagen
anterior.
  Ahora continuamos con el CONTROLADOR de nuestra aplicación, crea una clase
"controlador.java" en el paquete CONTROLLER, el código que debes colocar, es:

Explicación: Nuestra clase controlador, implementa el ActionListener, esto para responder

desde esta clase, los eventos realizados desde la interfaz (VISTA), además en el constructor
de la clase, vemos que se pasan como parámetros, la clase VISTA y la clase MODELO,
nuestra clase además cuenta las funciones, INICIAR() la cual inicializa los valores de la
interfaz, como ser el atributo título del JFrame, posicionamiento en pantalla, valores
iniciales de los jtextbox, etc. también tenemos el método actión performed el cual captura el
evento realizado desde la interfaz, en nuestro ejemplo es solo un CLICK EN EL BOTON
DE MENU SUMAR, obtiene los datos correspondientes e invoca al modelo para procesar
la información y obtener una respuesta.

 Para terminar debemos implementar todo esto en nuestro main.java:

Ejecuta el programa para terminar.

El patrón MVC, nos permite cambiar la interfaz de usuario (VISTA), sin tocar en lo
absoluto el MODELO de la aplicación, y realizar pequeños cambios en el controlador,
mínimos cambios, como se puede observar en la imagen superior, la interfaz 1, la cual fue
creada a través de este ejemplo, y además una segunda interfaz, totalmente distinta, sin
embargo funciona bajo el mismo MODELO.