Modelo-Vista-Controlador

1.Introducción
El patrón MVC (Trygve M. H. Reenskaug, ​http://heim.ifi.uio.no/~trygver/​) es un concepto
antiguo de la programación, existente desde los años 70. La máxima que persigue es tener
una buena separación de conceptos, dejando por un lado la lógica de la aplicación (modelo
de datos) y por otro lado la vista (interfaz gráfica). El controlador es el aparato software
encargado​ ​de​ ​conectar​ ​ambos.

A la hora de desarrollar una aplicación con interfaz gráfica de usuario podemos

encontrarnos con varias implementaciones. La primera de ellas, conocida con el nombre de
“Formularios y Controles” consiste en pensar primero en la interfaz, e introducir los datos de
la​ ​aplicación​ ​directamente​ ​en​ ​esta.

Pensemos por ejemplo en una aplicación para generar una Factura. Para ello deberíamos
tener un formulario o ventana, con los campos correspondientes a la factura. En la misma
clase que representa a nuestra ventana almacenaríamos los campos correspondientes a la
factura.

class​ ​Ventana​ ​{
​ ​String​ ​concepto;
​ ​BigDecimal​ ​precio;
​ ​int​ ​cantidad;

​ ​void​ ​show()​ ​{...}

}

Esta implementación presenta varios inconvenientes. En primer lugar, si quisiéramos

cambiar la vista, nos encontraríamos que el modelo de datos, en este caso la factura, está
diseminada por todo el código correspondiente a la interfaz gráfica. En segundo lugar, esta
mezcla​ ​de​ ​conceptos​ ​hace​ ​que​ ​el​ ​código​ ​sea​ ​mucho​ ​más​ ​difícil​ ​de​ ​probar​ ​y​ ​mantener.

2.El​ ​patrón
El patrón MVC propone una separación de conceptos, dejando por un lado ​el modelo de
datos, que es el que contiene la lógica de la aplicación y, por otro lado l​a vista, que es
la encargada de representar gráficamente los datos del modelo​. De esta manera
independizamos​ ​la​ ​lógica​ ​de​ ​negocio​ ​(es​ ​decir​ ​el​ ​modelo)​ ​de​ ​la​ ​interfaz​ ​gráfica.

Juan​ ​V.​ ​Carrillo

El modelo de datos incluye toda la lógica de negocio, es decir, lo que tiene que realizar el
software independientemente de la interfaz que utilice. En el ejemplo de la factura,
tendríamos la clase factura, la clase linea de factura, la clase cliente, la clase producto, la
clase IVA, etc. Estas clases no son solamente contenedores de datos, sino que tienen
método para interactuar entre ellas. Por ejemplo, factura tendría un método getTotal que
calcula​ ​el​ ​total​ ​de​ ​la​ ​factura​ ​sumando​ ​los​ ​subtotales​ ​de​ ​las​ ​líneas​ ​de​ ​factura.

class​ ​Factura​ ​{
private​ ​List<LineaFactura>​ ​lineas;
...
public​ ​BigDecimal​ ​getTotal()​ ​{
BigDecimal​ ​total​ ​=​ ​new​ ​BigDecimal(0);
lineas.forEach(linea​ ​->​ ​total​ ​=​ ​total.add(linea.getSubtotal()));
return​ ​total;
}
...
}

La vista (o vistas) debe incluir únicamente código correspondiente a la interfaz gráfica:

botones,​ ​campos​ ​de​ ​texto,​ ​layouts,​ ​formatos,​ ​colores,​ ​etc.

class​ ​LineaFactura{
​ ​ ​ ​ ​String​ ​concepto;
​ ​ ​ ​ ​BigDecimal​ ​precio;
​ ​ ​ ​ ​int​ ​cantidad;
}

class​ ​VentanaLinea​ ​{
​ ​ ​ ​ ​LineaFactura​ ​linea;
​ ​ ​ ​ ​void​ ​show()​ ​{...}
}

La tercera clase (o clases) que forma parte del patrón es el controlador, que se encarga de
actualizar el modelo en base a los cambios que realiza el usuario en la vista. El controlador
también se encarga de acciones que no pertenecen a la vista ni al modelo, como la
validación de datos. También es el encargado de seleccionar la mejor vista para mostrar el
modelo​ ​en​ ​cada​ ​momento.

Es importante no mezclar conceptos entre modelo, vista y controlador. Por ejemplo,

introducir datos del modelo en la vista, o viceversa, tal y como se hace en “Formularios y
Controles”. Asimismo, ​la vista no debe modificar directamente el modelo​, sino que debe

Juan​ ​V.​ ​Carrillo

hacerlo a través del controlador. También hay que tener en cuenta que tanto la vista como
el​ ​modelo​ ​y​ ​el​ ​controlador​ ​pueden​ ​estar​ ​conformados​ ​por​ ​varias​ ​clases.

Toda la operativa entre las diversas clases que conforman el patrón se realiza a través de
métodos y eventos. Los eventos se utilizan para que sea el propio modelo el que notifique a
la vista cuando se produce un cambio, para que ésta pueda actualizarse, evitando así una
espera activa. De igual manera, la vista notifica al controlador las acciones del usuario
(pulsar​ ​un​ ​botón,​ ​introducir​ ​texto,​ ​etc.)

Con este patrón conseguimos una buena separación de conceptos, así como una alta
cohesión de clases. Desde su aparición han surgido numerosas variaciones del mismo, con
el fin de adaptarlo a las características de la tecnología usada (web, escritorio, móvil, etc.).
Algunas​ ​de​ ​ellas​ ​son​ ​MVP​ ​(Model

● MVP​:​ ​Model-View-Presenter,​ ​patrón​ ​con​ ​separación​ ​por​ ​capas,​ ​implementado​ ​por

Microsoft.
● MVVM​:​ ​Model-View-ViewModel​ ​es​ ​una​ ​implementación​ ​de​ ​Microsoft​ ​del​ ​patrón
“Presentation​ ​model”,​ ​de​ ​Martin​ ​Fowler.​ ​La​ ​idea​ ​es​ ​utilizar​ ​clases​ ​que​ ​contienen
parte​ ​del​ ​modelo,​ ​o​ ​información​ ​de​ ​varias​ ​clases​ ​del​ ​modelo,​ ​que​ ​es​ ​necesario
mostrar​ ​en​ ​una​ ​vista​ ​concreta.
● MVW​:​ ​La​ ​última​ ​y​ ​más​ ​reciente​ ​reinterpretación​ ​de​ ​las​ ​siglas​ ​de​ ​este​ ​patrón​ ​es​ ​el
Model​ ​View​ ​Whatever,​ ​implementado​ ​en​ ​AngularJS​ ​por​ ​Google,​ ​ ​que​ ​sigue​ ​la
filosofía​ ​de​ ​Modelo​ ​+​ ​Vista​ ​+​ ​Lo​ ​que​ ​quieras​ ​usar​ ​o​ ​necesites.​ ​La​ ​flexibilidad​ ​se
ofrece​ ​con​ ​el​ ​controlador;​ ​no​ ​obstante,​ ​la​ ​vista​ ​y​ ​el​ ​modelo​ ​siempre​ ​se​ ​diseñan​ ​por
separado.

Juan​ ​V.​ ​Carrillo

 3.MVP
Una de las variaciones más implementadas del MVC es el MVP o Modelo Vista
Presentador. En esta versión, vamos un paso más allá en la separación de conceptos,
realizando un diseño por capas. El diseño por capas que ofrecen distintos servicios se ha
implementado numerosas veces en informática y generalmente con éxito. El modelo más
famoso​ ​que​ ​conocemos​ ​es​ ​el​ ​de​ ​funcionamiento​ ​de​ ​la​ ​red​ ​o​ ​modelo​ ​OSI.

En este caso, el diseño que realizamos consiste en separar la vista del modelo, haciendo
que la comunicación entre ambos siempre se realice a través del controlador. El modelo no
define siquiera observers, por lo que la separación de la lógica
de negocio del resto de la aplicación es mayor, pues
eliminamos de las clases de negocio (modelo) el código
correspondiente a los eventos. ​El controlador actúa como
supervisor​ ​del​ ​modelo​ ​y​ ​avisa​ ​a​ ​la​ ​vista​ ​de​ ​los​ ​cambios.

Como ventajas, obtenemos una aplicación más fácil de probar,

pues el modelo no depende en absoluto de la vista para poder
ser probado. Además, será más sencillo seguir añadiendo
capas a la aplicación si, por ejemplo, necesitamos persistencia
en​ ​una​ ​base​ ​de​ ​datos​ ​o​ ​comunicación​ ​a​ ​través​ ​de​ ​una​ ​red.

Con esta implementación no sólo conseguimos una ​alta

cohesión, sino también un bajo acoplamiento, que son los
dos​ ​principios​ ​básicos​ ​de​ ​un​ ​buen​ ​diseño​ ​orientado​ ​a​ ​objetos.

4.Programación​ ​MVP​ ​en​ ​Java​ ​Swing

En​ ​el​ ​ejemplo​ ​que​ ​se​ ​adjunta​ ​a​ ​este​ ​documento​ ​podemos​ ​ver​ ​la​ ​implementación​ ​del​ ​MVP​ ​en
una​ ​aplicación​ ​con​ ​Swing.​ ​Se​ ​trata​ ​de​ ​la​ ​aplicación​ ​de​ ​facturas​ ​aunque,​ ​por​ ​sencillez​ ​a​ ​la
hora​ ​de​ ​mostrar​ ​el​ ​patrón,​ ​se​ ​ha​ ​reducido​ ​a​ ​una​ ​interfaz​ ​en​ ​la​ ​que​ ​se​ ​da​ ​de​ ​alta​ ​una​ ​línea​ ​de
la​ ​factura.​ ​El​ ​modelo​ ​constaría​ ​por​ ​tanto​ ​de​ ​dos​ ​clases:​ ​Producto​ ​y​ ​LineaFactura

La​ ​ventana​ ​será​ ​la​ ​encargada​ ​de​ ​mostrar​ ​la​ ​línea​ ​y​ ​dará​ ​opción​ ​a​ ​modificarla.​ ​En​ ​este
ejemplo​ ​nos​ ​podemos​ ​encontrar​ ​dos​ ​flujos​ ​de​ ​trabajo:

Juan​ ​V.​ ​Carrillo

 1. Cargar la ventana​: cuando se carga la ventana, si hay datos previamente, es decir,
existe la línea de factura, se tienen que cargar estos datos en la vista. Para ello, será
el​ ​controlador​ ​el​ ​que​ ​establezca​ ​la​ ​línea​ ​en​ ​la​ ​vista.
2. Guardar cambios​: al guardar los datos de la línea, la vista avisa al controlador de
que quiere realizar un cambio en el modelo (IMPORTANTE: no modifica el modelo
directamente). Es el controlador el encargado de validar los cambios e introducirlos
en el modelo. Al cambiar la cantidad o el producto, se guardan los datos en el
modelo​ ​y​ ​se​ ​modifica​ ​la​ ​vista​ ​para​ ​que​ ​muestre​ ​el​ ​nuevo​ ​subtotal.

En el código de ejemplo se ha separado el controlador en una clase distinta para reforzar la

separación de conceptos. La clase controlador separada del código del JFrame tiene
sentido cuando se controlan varias ventanas o el código del controlador tiene la entidad
suficiente (cantidad de métodos y líneas de código). No obstante, para tareas tan triviales,
nos puede interesar tener el código del controlador en la misma clase que el JFrame. Esto
es​ ​debido​ ​a​ ​la​ ​arquitectura​ ​de​ ​Java​ ​Swing,​ ​como​ ​veremos​ ​en​ ​el​ ​siguiente​ ​apartado.

5.MVC​ ​en​ ​Java​ ​Swing

El propio framework de Java Swing está programado siguiendo el patrón MVC. Así, cada
componente se construye a través de varias clases que definen cómo se ve y se comporta.
El ejemplo más claro lo podemos ver en las clases más complejas, como JTable. En un
JTable​ ​tenemos:

● Las​ ​clases​ ​de​ ​vista​ ​y​ ​controlador​ ​(JTable)​ ​que​ ​definen​ ​cómo​ ​se​ ​ve​ ​la​ ​tabla​ ​y​ ​cómo
reacciona​ ​ante​ ​la​ ​interacción​ ​con​ ​el​ ​usuario.
● La​ ​clase​ ​modelo​ ​son​ ​dos:​ ​TableModel,​ ​que​ ​contiene​ ​los​ ​datos,​ ​y​ ​TableColumnModel,
que​ ​define​ ​las​ ​columnas​ ​que​ ​se​ ​muestran,​ ​columnas​ ​que​ ​pueden​ ​ser​ ​seleccionadas,
orden​ ​de​ ​las​ ​mismas,​ ​etc.

Juan​ ​V.​ ​Carrillo

Si bien es cierto que JFC implementa el MVC, se puede decir que se está usando una
variación del mismo conocida como “Model Delegate”, en el que la parte relativa a la vista y
al controlador se implementa con una única clase; en este caso, el ​User Interface (UI)
Delegate.​ ​Fuente:​ ​http://c2.com/cgi/wiki?ModelDelegate

6.Referencias
● Model-View-Controller.​ ​http://c2.com/cgi/wiki?ModelViewController
● The​ ​MVC​ ​pattern​ ​implemented​ ​with​ ​java​ ​swing
https://www.link-intersystems.com/blog/2013/07/20/the-mvc-pattern-implemented-wit
h-java-swing/
● A​ ​Swing​ ​Architecture​ ​Overview.​ ​The​ ​Inside​ ​Story​ ​on​ ​JFC​ ​Component​ ​Design.​ ​By
Amy​ ​Fowler.​ ​http://www.oracle.com/technetwork/java/architecture-142923.html
● GUI​ ​Architectures.​ ​Martin​ ​Fowler​ ​http://martinfowler.com/eaaDev/uiArchs.html
● MVC​ ​or​ ​MVP​ ​Pattern​ ​–​ ​Whats​ ​the​ ​difference?
http://www.infragistics.com/community/blogs/todd_snyder/archive/2007/10/17/mvc-or
-mvp-pattern-whats-the-difference.aspx
● Presentation​ ​Model.​ ​Martin​ ​Fowler.
http://martinfowler.com/eaaDev/PresentationModel.html
● MVW​ ​https://plus.google.com/+AngularJS/posts/aZNVhj355G2

Juan​ ​V.​ ​Carrillo