Qué es MVC

  • Por
Te explicamos de manera general MVC, Model - View - Controller o Modelo - Vista - Controlador un patrón de diseño de software para programación que propone separar el código de los programas por sus diferentes responsabilidades.

En líneas generales, MVC es una propuesta de diseño de software utilizada para implementar sistemas donde se requiere el uso de interfaces de usuario. 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.

Su fundamento es la separación del código en tres capas diferentes, acotadas por su responsabilidad, en lo que se llaman Modelos, Vistas y Controladores, o lo que es lo mismo, Model, Views & Controllers, si lo prefieres en inglés. En este artículo estudiaremos con detalle estos conceptos, así como las ventajas de ponerlos en marcha cuando desarrollamos.

MVC es un "invento" que ya tiene varias décadas y fue presentado incluso antes de la aparición de la Web. No obstante, en los últimos años ha ganado mucha fuerza y seguidores gracias a la aparición de numerosos frameworks de desarrollo web que utilizan el patrón MVC como modelo para la arquitectura de las aplicaciones web.

Nota: Como ya hemos mencionado, MVC es útil para cualquier desarrollo en el que intervengan interfaces de usuario. Sin embargo, a lo largo de este artículo explicaremos el paradigma bajo el prisma del desarrollo web.

Por qué MVC

La rama de la ingeniería del software se preocupa por crear procesos que aseguren calidad en los programas que se realizan y esa calidad atiende a diversos parámetros que son deseables para todo desarrollo, como la estructuración de los programas o reutilización del código, lo que debe influir positivamente en la facilidad de desarrollo y el mantenimiento.

Los ingenieros del software se dedican a estudiar de qué manera se pueden mejorar los procesos de creación de software y una de las soluciones a las que han llegado es la arquitectura basada en capas que separan el código en función de sus responsabilidades o conceptos. Por tanto, cuando estudiamos MVC lo primero que tenemos que saber es que está ahí para ayudarnos a crear aplicaciones con mayor calidad.

Quizás, para que a todos nos queden claras las ventajas del MVC podamos echar mano de unos cuantos ejemplos:

  1. Aunque no tenga nada que ver, comencemos con algo tan sencillo como son el HTML y las CSS. Al principio, en el HTML se mezclaba tanto el contenido como la presentación. Es decir, en el propio HTML tenemos etiquetas como "font" que sirven para definir las características de una fuente, o atributos como "bgcolor" que definen el color de un fondo. El resultado es que tanto el contenido como la presentación estaban juntos y si algún día pretendíamos cambiar la forma con la que se mostraba una página, estábamos obligados a cambiar cada uno de los archivos HTML que componen una web, tocando todas y cada una de las etiquetas que hay en el documento. Con el tiempo se observó que eso no era práctico y se creó el lenguaje CSS, en el que se separó la responsabilidad de aplicar el formato de una web.
  2. Al escribir programas en lenguajes como PHP, cualquiera de nosotros comienza mezclando tanto el código PHP como el código HTML (e incluso el Javascript) en el mismo archivo. Esto produce lo que se denomina el "Código Espagueti". Si algún día pretendemos cambiar el modo en cómo queremos que se muestre el contenido, estamos obligados a repasar todas y cada una de las páginas que tiene nuestro proyecto. Sería mucho más útil que el HTML estuviera separado del PHP.
  3. Si queremos que en un equipo intervengan perfiles distintos de profesionales y trabajen de manera autónoma, como diseñadores o programadores, ambos tienen que tocar los mismos archivos y el diseñador se tiene necesariamente que relacionar con mucho código en un lenguaje de programación que puede no serle familiar, siendo que a éste quizás solo le interesan los bloques donde hay HTML. De nuevo, sería mucho más fácil la separación del código.
  4. Durante la manipulación de datos en una aplicación es posible que estemos accediendo a los mismos datos en lugares distintos. Por ejemplo, podemos acceder a los datos de un artículo desde la página donde se muestra éste, la página donde se listan los artículos de un manual o la página de backend donde se administran los artículos de un sitio web. Si un día cambiamos los datos de los artículos (alteramos la tabla para añadir nuevos campos o cambiar los existentes porque las necesidades de nuestros artículos varían), estamos obligados a cambiar, página a página, todos los lugares donde se consumían datos de los artículos. Además, si tenemos el código de acceso a datos disperso por decenas de lugares, es posible que estemos repitiendo las mismas sentencias de acceso a esos datos y por tanto no estamos reutilizando código.

Quizás te hayas visto en alguna de esas situaciones en el pasado. Son solo son simples ejemplos, habiendo decenas de casos similares en los que resultaría útil aplicar una arquitectura como el MVC, con la que nos obliguemos a separar nuestro código atendiendo a sus responsabilidades.

Ahora que ya podemos tener una idea de las ventajas que nos puede aportar el MVC, analicemos las diversas partes o conceptos en los que debemos separar el código de nuestras aplicaciones.

Modelos

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.

Vistas

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.

Controladores

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.

Arquitectura de aplicaciones MVC

A continuación encontrarás un diagrama que te servirá para entender un poco mejor cómo colaboran las distintas capas que componen la arquitectura de desarrollo de software en el patrón MVC.

En esta imagen hemos 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. Veamos paso a paso cómo sería el flujo de trabajo característico en un esquema MVC.

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Lógica de negocio / 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, pensemos en un sistema que implementa usuarios. Los usuarios pueden realizar comentarios. Pues si en un modelo nos piden eliminar un usuario nosotros debemos 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.

Nota: 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 comenarios 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.

Nota: 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.

Otro ejemplo. Tenemos un sistema para borrar productos. Cuando se hace una solicitud a una página para borrar un producto de la base de datos, se pone en marcha un controlador que recibe el identificador del producto que se tiene que borrar. Entonces le pide al modelo que lo borre y a continuación se comprueba si el modelo nos responde que se ha podido borrar o no. En caso que se haya borrado queremos mostrar una vista y en caso que no se haya borrado queremos mostrar otra. Este proceso también está en los controladores y lo podemos denominar como lógica de la aplicación.

De momento ¡eso es todo! Esperamos que este artículo haya podido aclarar los distintos conceptos relacionados con el MVC y aunque no hayamos visto una implementación en código, te sirva para poder investigar a partir de aquí. En DesarrolloWeb.com hemos tratado con mayor detalle algunos aspectos de MVC y la relación entre vistas y modelos y sus interpretaciones en un artículo que seguro te interesará. Además podrás ver cómo trabajar con MVC en el Manual de Codeigniter, en el Manual de Laravel y en el Manual del framework ASP.NET MVC.

Paralelamente queremos que conozcas nuestra plataforma para la formación EscuelaIT, donde podrás aprender con nosotros todo sobre este MVC y otros asuntos relacionados con la arquitectura del software en este curso de MVC y otras Técnicas de desarrollo de aplicaciones web en PHP.

Autor

Miguel Angel Alvarez

Miguel es fundador de DesarrolloWeb.com y la plataforma de formación online EscuelaIT. Comenzó en el mundo del desarrollo web en el año 1997, transformando su hobby en su trabajo.

Compartir

Comentarios

iLManga

02/1/2014
Resolucion o ubicacion de lo de compartir
Amigos primero que nada infinitas gracias por la labor que prestan, desde Venezuela se les saluda, gracias a ustedes he podido aprender practicamente todo lo que se desde el 2003, aunque no es el lugar oportuno queria advertirles sobre la ubicacion de los botones de las redes sociales, queda muy abajo en el caso del boton del facebook, antonces cuando aparece la capa el boton "compartir" no se ve, tuve que encoger la ventana del chorme para subirla, espero haberme explicado.

edgardo

03/1/2014
interesante
Buen articulo, saludos.-

Lain

04/1/2014
Comentario
Sólo para aclarar que el Controlador no representa la lógica de negocio en el patrón MVC.
El MODELO es una representación de los datos de la aplicación o del estado, y contiene (o proporciona una interfaz a) la lógica de aplicación.
El CONTROLADOR sólo gestiona la interacción entre el Modelo y la Vista.

Alejandro

12/8/2014
Excelente Trabajo!
Saludos desde México, esta información es muy clara y precisa, me sirvió de mucho para entender todo lo relacionado con el MVC, muchas gracias! Sigan así :)

Enrique

09/9/2014
Enhorabuena
Enhorabuena por la entrada, explica de una manera muy concisa y clara el modelo MVC

Camilo Alberto Prieto Rodriguez

01/10/2014
Buenisimo!!!
Muy claros en el articulo...sencillo de entender

Alberto Palanque

08/10/2014
Me habéis aclarado
Muchas de las cosas que no entendía de MVC ahora las tengo mucho más claras.
Gracias.

Lucas Alcántara

14/10/2014
Qué otros patrones de diseño aplican en el desarrollo de web?
Hola,
Por favor, necesito saber qué otros patrones de diseño aplican o se usan en el mundo del desarrollo de sitios web. Gracias!

jorge_ganchozo

01/3/2015
Interesante
Felicitaciones colegas.... totalmente entendible la guía ... !!!

modelizador

27/3/2015
los modelos no deben conocer a las vistas
Yo soy de los que creen que las vistas no deben pedir nada a los modelos directamente, los modelos y las vistas no se conocen entre si. en todo caso será el controlador el que pase la información a las vistas.

Sylvia

12/6/2015
Muy claro todo
Me hice un verdadero lío cuando me explicaron este concepto en un curso de la formación de grado en mi instituto, pero con vosotros en 5 minutos me ha quedado perfectamente claro qué es el mvc. gracias!

Sainz

29/6/2015
Muy bien explicado.
Me gusto el artículo,esta explicado para entender,aunque quisiera agregar también ,que el patrón MVC también permite multiples vistas ,donde cada vista tiene su controladora.Gracias espero que les sea de ayuda .

Andy

05/7/2015
Excelente Articulo
Muy buen articulo para entender de manera macro el funcionamiento del Modelo MVC. Gracias amigos.

ANTONIO

22/7/2015
MUCHAS GRACIAS DE NUEVO
Está claro la explicación gracias amigo por las ganas que tienes de enseñar a los demás.

Harold

07/9/2015
MVC no es un patrón de diseño
MVC no es un patron de diseño, es un patron de arquitectura de software que utiliza algunos patrones de diseño como Observer, command entre otros. Hay que aclarar el concepto.

jullio

09/9/2015
duda
es que tenemos que hacer un programa en grupo y me dijeron que me tocaba el view model a que se quisieron refererir

Alberto Salamanca

19/2/2016
Muy bueno
Gracias por el articulo está muy claro y fácil de enender.

Francisco

05/3/2016
Pruebas y Manejo de Errores
Hola
Estoy estudiando este modelo MVC y me preguntaba si podrías decirme las pruebas y manejo de errores que se deben tomar en cuenta para implementar este modelo

JLuis

06/4/2016
MVC
Gracias, he visto la luz!

Raúl

25/7/2016
Excelente explicación
Se aclararon mas cosas con este articulo bien hecho sigan asi.

Saludos.

Katifranco

19/10/2016
Qué es MVC
Solo me queda darte las gracias ... me parece que es un buen inicio para comenzar en MVC

Felipe

27/12/2016
El mejor sitio
Este sitio es muy antiguo en la NET, tanto asi que pasaba de largo ya cuando queria informarme sobre alguna cosa. Pero ahora que le estoy redescubriendo me doy cuenta que son realmente excelentes para explicar informacion y hacer manuales.
Los feclicito de verdad, cuando necesite hacerme un curso on line los tendre muy presente a ustedes,

saludos

Laura Tapia

10/4/2017
Excelente
Excelente la explicación, lo he entendido muy facilmente, gracias, felicidades por tu gran trabajo

Jflores

26/4/2017
Articulo
Excelente trabajo.. Saludos

Adolfo Ubilla

11/6/2017
Explicacion de Temas
Hola Señores "DesarrolloWEB.com", he leído una serie de artículos de ustedes para ponerme al día en desarrollo de sistemas y he observado que en cada uno lo hacen con gran sencillez y claridad que nos permite a los lectores entenderlos y comprender los temas. Gracias por sus excelentes temas y les deseos éxitos en sus labores