Patrón Model-View-Controller

Model-View-Controller

La amplia mayoría de las arquitecturas de presentación comparten la idea de dividir el problema en tres partes llamadas modelo, vista y controlador; a esto se lo llama patrón MVC. Sin embargo, existen grandes diferencias a la hora de determinar la naturaleza exacta de cada una de esas partes, cómo deben comunicarse entre sí o incluso se discute sobre si determinadas responsabilidades debieran caer en uno u otro de los tres actores. 
Como ya se dijo, nosotros nos vamos a concentrar en una de todas las posibles formas de interpretar este patrón. En la literatura, a esta interpretación se la identifica como MMVC o (más recientemente) MVVM. (Las siglas surgen de desarrollos independientes entre sí, pero que tienen muchos puntos de contacto.)

Las características salientes de la visión del MVC que vamos a presentar son:
  • El uso extensivo de objetos para modelar tanto modelos como vistas y controladores.
  • El uso de eventos para manejar la comunicación entre vista y modelo (y además una forma específica de interrelacionar los eventos denominada binding)
  • La reducción de los controllers a su mínima expresión, quitándoles responsabilidades y minimizando su complejidad.
  • La aparición de un elemento extra denominado application model (en MMVC) o view model (en MVVM), que toma preponderancia en desmedro de los controllers.

Desde esta perspectiva, definimos modelo, vista y controlador así:
  • El modelo contiene el comportamiento de la aplicación. Como primera aproximación podemos asociar modelo con "modelo de dominio", pero más adelante vamos a ver que pueden aparecer otros tipos de modelo. 

    Para que el modelo logre cumplir su cometido de contener toda la lógica de la aplicación, hay dos situaciones que debemos evitar o minimizar:
    • La aparición de lógica propia del dominio en los demás componentes (vista o controlador).
    • La contaminación del modelo con elementos propios de la interacción del usuario y con cualquier cuestión relacionada con la tecnología. 
  • La vista tiene la responsabilidad de interactuar con el usuario. Para ello cuenta (por lo menos) con:
    • Elementos visuales que muestran información al usuario o que permiten al usuario ingresar información o interactuar con ellos (por ejemplo con el teclado o el mouse). A estos elementos visuales se los suele denominar controles o widgets.
    • Contenedores para los controles, como ventanas y paneles.
    • Estrategias para organizar visualmente los controles dentro de un contenedor, denominadas layouts.
Dado que elegimos una estrategia basada en objetos, tanto los controles básicos como los contenedores y layouts estarán modelados como objetos. Normalmente esos objetos no requieren de ser programados por nosotros, en cambio el framework nos provee de un conjunto de componentes primitivos listos para ser utilizados. Entonces nuestro código para la vista se limita a la parte creacional: crear los controles, agregarlos a algún contenedor, asignarle un layout al contenedor, etc.
  • El controlador tiene la responsabilidad de comunicar a la vista con el modelo. Esta comunicación está basada en dos conceptos que ya mencionamos pero todavía no definimos con precisión: eventos y binding. Esta es la parte más compleja y es de lo que van a tratar las próximas secciones.

    Como dijimos, nuestra estrategia será minimizar las responsabilidades que asignamos a los controllers. Esto se debe a que los controllers son componentes que están muy ligados a problemáticas tecnológicas, entonces, poner lógica en ese lugar suele llevar a aplicaciones que resultan difíciles de mantener, de modificar, de garantizar que no tengan errores.

    Para minimizar la complejidad del controlador, en las primeras aplicaciones que hagamos las vistas serán muy parecidas a los modelos. Por ejemplo si nuestro modelo es un objeto Película que tiene un título, un director y una lista de actores, se mostrará en una ventana que tenga un control para cada atributo de la Película. Es decir, (por ahora) a cada pantalla de la vista la vamos a asociar con un único objeto del modelo y vamos a establecer una relación uno a uno entre los controles de la vista y los atributos del modelo
    A veces esa regla parece muy estricta, sin embargo nuestra arquitectura establece que el modelo tiene el comportamiento de la aplicación y la vista sólo debe exponer ese comportamiento al usuario. Entonces, si tengo una vista que necesita hablar con muchos modelos, eso puede considerarse un bad smell, y debería revisar si no me está faltando un objeto en ese modelo. De cualquier manera, esta regla nos va a servir para comenzar, y a medida que vayamos teniendo más claros los conceptos básicos vamos a poder analizar en qué casos conviene relajarla.

Temas Relacionados


Comments