Modelo Vista Controlador

¡Bienvenidos un día más a un nuevo rootie queridos amigos! Hace unas semanas, prometí que un Jueves aparecería con este post, pero por cosas de la vida, se quedo en el tintero, pero hoy lo he terminado y me enorgullece de poder traerlo con antelación, ¡porque es miércoles! Así que sin más dilación, ¡bienvenidos al rootie sobre Modelo Vista Controlador (MVC)!

mejor tarde que nunca
No ha colado lo de que vengo con antelación ¿no?

Para los que no os habéis leído mi rootie sobre patrones de diseñoMVC es un la abreviatura de Modelo Vista Controlador y en los últimos años se ha hecho tremendamente popular o por lo menos lo puedes encontrar en casi cualquier empresa.

El modelo MVC no es una nueva arquitectura surgida hace cuatro días, su primera aparición se remonta a los años 70 gracias a Trygve Reenskaug que lo formulo por primera vez..

Entendiendo el patron Modelo Vista Controlador.

Este patron es uno de las primeras ideas relacionadas con la interfaz de usuario y además fue, también, de los primeros patrones en describir e implementar soluciones de software en base a sus diferentes funciones.

De forma genérica, podemos describir los componentes de MVC de la siguiente forma:

  • Modelo: Es la información con la cual el sistema trabajar. Es el mismo sistema quien gestiona los accesos a la información (consultas, creación, actualización, etc) respetando siempre la lógica de negocio definida. El Modelo actúa (normalmente) a petición del Controlador y nos devolverá la información que queramos devolver al usuario.
  • Controlador: Es el encargado de interactuar con la Vista y el Modelo. El Controlador normalmente responderá ante peticiones del usuario y facilitará tanto la gestión de la información como le procesamiento de la misma para enviar a la Vista la información necesaria. Por ejemplo al acceder a un listado de usuarios, sera el controlador quien implemente los diferentes mecanismos para mostrar dicha lista como pueden ser el solicitar la información al Modelo y enviarla a la vista para su renderizado.
  • Vista: La vista presenta la información previamente procesada por el Controlador y extraída del Modelo de una forma adecuada, que facilite el uso al usuario.

Interacción entre los componentes.

MVC hoy en día tiene diferentes variantes (HMVC, MVP, MVVM, etc.), pero el flujo de control es fundamentalmente el siguiente:

  1. El usuario interactúa con la interfaz de usuario.
  2. El Controlador recibe desde la vista la notificación de la acción realizada por el usuario. El controlador gestiona el evento a través de un gestor de eventos (handler).
  3. Este evento es gestionado por el Controlador, pudiendo crear un nuevo objeto, actualizarlo, eliminarlo etc.
  4. La Vista recibe del Controlador la información necesaria y esta se encarga de generar la interfaz adecuada.
  5. Finalmente, el sistema queda a la espera de nuevas interacciones por parte del usuario.
modelo vista controlador diagrama
Diagrama de interaccion Modelo Vista Controlador.

 Uso en aplicaciones web.

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.

Actualmente podemos encontrar una gran variedad de frameworks que hacen uso de MVC, la diferencia principal entre dichos frameworks se encuentra en si el patrón Modelo Vista Controlador es aplicado en el cliente o en el servidor.

Eligiendo MVC.

Elegir una arquitectura para un proyecto es algo tan subjetivo como ponerte unos calzoncillos. Te has de poner los adecuados para cada ocasión

Yo siempre elijo los marianos, comfort y comodidad para la dura vida del rooter

Pero desde luego si estas en la fase final de elección y dudas entre otra arquitectura o MVC, aquí tienes una lista de cosas a favor:

  • MVC sigue el principio de separación de intereses, con lo que su mantenimiento es muy sencillo. Se pueden realizar cambios en cualquier capa de la aplicación sin afectar necesariamente al resto.
  • Facilidad a la hora de realizar test unitarios.
  • Lógica de negocio e interfaz separadas. Permitiendo un código de mucha mejor calidad y con un mantenimiento mucho mas sencillo.
  • Reducción de código duplicado.
  • Reusabilidad aumentada, ya que la lógica de negocio, puede servir para varias vistas.

Y la lista no termina aquí con lo que puede parecer a primera vista una buena idea. MVC también tiene sus contras y para ser justos os voy a dejar una lista (pero no tan larga jijiji)

  • El Controlador puede crecer tanto que termine siendo un cuello de botella. Para evitar esto, a mi me gusta crear servicios y utilizar inyección de dependencias.
  • MVC es un paradigma. Por lo tanto no especifica nada acerca de como ejecutar el acceso a datos.
  • Siendo sinceros, es un patrón de diseño complejo. Se necesita de un buen entendimiento del flujo de control entre los componentes.
  • Relacionado con este último punto, MVC exige que ademas conozcas otras técnicas y patrones, como pueden ser el AutoloadingDependency Injection, etc

Y con esto damos por finalizado nuestro rootie sobre MVC. Lo más seguro es que escriba algún otro post sobre MVC y sus derivados en un futuro cercano, hasta entonces, ¡nos vemos el jueves! 

 

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *