MVC en la web, la gran farsa de los arquitectos de software

27 de enero, 2011 - por

En los entornos de desarrollo web es habitual referirse al patrón de diseño Modelo Vista Controlador (MVC) como la “forma correcta” de construir sitios/aplicaciones web. La realidad es que dicho patrón no se puede aplicar a la web tal y como se concibió, aunque su objetivo resulte útil y entronque con un principio general de diseño frecuente en distintos entornos de desarrollo de software: separar claramente las partes de un sistema. Así de sencillo. :)

Modelo-Vista-Controlador

El paradigma MVC, tal como se presentó originalmente, está pensado para aplicaciones estáticas como las que solemos manejar en un entorno de escritorio. Piensa por ejemplo en tu organizador de archivos (en Windows, en Mac o en Linux): te ofrece un buen número de botones, campos de entrada, controles de ventana, filtros, etc., que pueden ser presionados por ti en cualquier momento. Cuando lo haces, estás activando uno de los muchos “controladores”, su consecuente “modelo” para hacer lo que tiene que hacer, y finalmente actualizando una o más “vistas” que reflejarán el nuevo estado del “modelo”. En la implementación original la cosa quedaba descrita del siguiente modo:

The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

Es decir, el problema original al que se enfrentaba este “paradigma” era la simultaneidad, en un entorno de múltiples puntos de entrada (en forma de “controladores”) y múltiples puntos de salida (en forma de “vistas”). Lo que nos obliga a preguntarnos: ¿la web es un entorno de ese tipo? Evidentemente no. En la web manejas un sólo punto de entrada (request) y un sólo punto de salida (response), por lo que para empezar te encuentras con un patrón para el cual no dispones de un problema real sobre el que aplicarlo. :(

Pero además te encuentras con que las aplicaciones ideales para MVC son básicamente monousuarias y el modelo se mantiene en memoria mientras la aplicación está siendo ejecutada. Segundo elemento que no encontramos en la web: entorno típicamente multiusuario, donde el modelo para el usuario se regenera en cada request.

Si uno profundiza en las características del paradigma original se irá encontrando con más diferencias, que básicamente son fruto de estas dos básicas que he señalado.

Separa, separa, separa

Si el patrón original no puede ser aplicado realmente a los problemas típicos con los que nos enfrentamos en un entorno web, ¿qué es lo que podemos extraer de él? Sin duda alguna, su vocación por mantener separadas las partes de un sistema: es decir, pon tu código de datos en un lado, tu código de aplicación en otro, y tu código de presentación en otro. No suena a nada del otro mundo, dicho así; parece sentido común, y es al mismo tiempo una forma tradicional de desarrollo de software que encaja muy bien con trabajo en equipo y especializado.

Por lo tanto, no tiene sentido apelar a este patrón como una solución-para-todo, e incluso puede resultar contraproducente, puesto que se van a estar forzando las cosas (las palabras, los conceptos, etc.) y por lo tanto perdiendo perspectiva. Eso en el mejor de los casos; en el peor, se llegará a construir un problema ajustado al patrón y no a la inversa. :(

Tema: Análisis, Desarrollo, Diseño

Etiquetas: , , , , , , .


Otras entradas que pueden interesarte

hay 10 comentarios para esta entrada

  1. Enrique Gomez dice:

    Y que con Spring Web MVC o Struts? Lo he utilizado exitosamente en mis aplicaciones y no he tenido problemas. Todo con patrones de diseño web y utilizando aplicaciones Spring Web MVC….Que me dices al respecto?

  2. grosshat dice:

    @Enrique
    Claro, el post no va sobre si funcionan o no. Mi opinión es que la práctica del MVC en la web está más cerca de ser una idea general sobre separación de componentes, que del patrón original diseñado por Steve Burbeck. Creo que muchas veces se infla de jerga y academicismo una práctica corriente en programación.

  3. @dk4nno dice:

    Apoyo totalmente tu posición, MVC es un paradigma totalmente aceptable para el desarrollo de software, pero no el único, y tampoco tratar de “revolucionar” el desarrollo bajo web, pues la inconmensurabilidad se apodera en este tema..

  4. frank dice:

    Pues he trabajado con mvc, es verdad que se separa la logica, el diseño y la negociacion, pero en contra se vuelve ya demasiado complicado para personas que no tienen experiencia, ademas de ser mas laborioso, lo mismo se puede lograr programando correctamente los modulos del site.

    Yo personalmente he encontrado mas desventajas que ventajas en este modelo.

  5. grosshat dice:

    @frank
    Sí, para mí también lo importante es separar correctamente. Y en cualquier caso, no necesitar la referencia de un patrón de diseño tan complejo para organizar una separación de las tres capas.

  6. Alberto Ocotitla dice:

    No concuerdo en todo lo que se menciona, me explico; es cierto que la arquitectura MVC no es para todo ni para todos, por ejemplo intentar hacer una página web con MVC es absurdo, es complicarse la existencia y es demostrar que no se ha comprendido MVC, pero si hablamos de un sistema ERP (ya sea en web o no) la historia es muy diferente, por ejemplo un reporte trimestral de ventas, da igual si lo presentas en pdf, excel o html, los datos son los mismos, lo único que cambia es la vista, aquí si se aprovecha la arquitectura pues lo único diferente es la presentación, no los datos (el modelo), ni el controlador.

    Es natural mostrar resistencia al principio, en mi caso cuando comencé con MVC asumía erróneamente que tenia que elegir entre AJAX o MVC, algo similar a considerar POO y Cliente-Servidor como paradigmas excluyentes, pero obviamente no es así, puedes desarrollar vistas con AJAX, utilizar POO y además todo dentro una arquitectura MVC.

  7. Lanreb Otrelba dice:

    Hola a todos, en primer lugar agradecer a Iñigo por darnos la oportunidad de debatir sobre este tema… estoy de acuerdo con el comentario de Alberto. Tb estoy de acuerdo en que una sencilla aplicación web que presenta unas consultas generadas en el momento para un determinado usuario(bajo petición) posiblemente no tiene porqué aplicar MVC. Sin embargo si tu aplicación recibe datos de multiples fuentes, usuarios incluidos, los almacena en memoria, en base de datos, etc., y luego actualiza los interfaces de los demás usuarios con lo que se ha recibido / procesado (p.e. una “sencilla” aplicación de chat a través de web, no hace falta irse a un ERP ;-D ) si que cumple con las características previstas para MVC. Esto es independiente que en alguna capa de la comunicacion entre el interfaz de usuario y el resto de elementos sólo dispongas de un mecanismo de petición-respuesta (como HTTP). En mi opinión en general recomiendo siempre aplicar MVC porque a pesar de que te cueste más esfuerzo, hace que tu aplicación sea más fácilmente mantenibles, facilita la reutilización del modelo y quien sabe, quizá algo que empezó como una sencilla aplicación, luego resultó ser algo más complicada y llega a cumplir las condiciones… inviertes hoy para ahorrar en un futuro.

  8. wiggin dice:

    respondiendo a algunos comentarios al respecto, especialmente aquéllos que dicen que usar el MVC es más “complejo” o como mínimo requiere más tiempo para programar; yo creo, que usando lar herramientas adecuadas, es mucho mejor basarse en esta arquitectura, ya que te permite tener todo mucho más organizado, además de que si te ayudas de “frameworks”, como por ejemplo symfony para php, o spring para java; y te tomas la molestia de aprender a usarlo, entonces realmente puedes ver las ventajas que te aporta esta arquitectura, especialmente, cuando utilizas las herramientas adecuadas para centrarte en tu aplicación web. Ya que como muy bien dice Lanreb Otrelba, puede parecer más comodo crear todo con “Modulos”, pero siguiendo unos patrones, y unas buenas practicas de programación, que se te facilitan más cuando usas un framework creo te puede servir para curarte en salud y adelantarte a muchos problemas que luego te pueden surgir si quieres ampliar o modificar tu “aplicación” web. A nosotros nos enseñaron el MVC, tanto en ap. web, como en local, en ap. web; usamos struts y es muy versatil y muy potente, porque tienes el código completamente separado, y te permite hacerg grandes modificiaciones sin problemas).

    A mi, también me gusta usar un ORM, o directamente un ODBMS, en mi opinión es muy útil ya que también ayuda a mantener el codigo más “limpio” y es más flexible, que atacar la base de datos directamente, aunque con esto si que hay que ir un poco más con cuidado, especialmente si tu base de datos es muy concurrida, ya que no todos los ORM son igual de eficientes, y la tecnologia de los ODBMS esta poco extendida.

  9. Noe De La Rosa dice:

    Buenno, este articulo esta verdaderamente interesante, existe una buena pinceladas de realidad la Web es(reques y Response) y MVC es multiTareas, Estados Dinamicos, Multi-Salidas.. asi que si estoy de acuerdo con este articulo, es un metodo en cajado en un modelo. por eso Silverligh talvez fue Matado y no digo que solo por eso. Y con respecto a un chico que dijo que en este modelo ha encontrado mas desventajas que ventajas: digo lo siguiente, Para hacer una ventana y un boton la programacion habitual es fenomenal, pero cuando tienes Teem trabajando en algo Grande, De embergadura, lo tradicional se vuelve un fastidio y NO HABLAR DE MANTENIMIENTO.. ES ES UN VERDADERO DEMONIO ANDANTE EN LA PROGRAMACION TRADICIONAL. lo que pasa es como yo digo el modelo para el inicio de una aplicacion con este modelo(MVC) es mas pesado pero despues que arranco el resultado es Execepcional.

    Gracias.

  10. Eduardo dice:

    Si te gusta MVC usalo, si no sigue con tu propia forma de trabajo … ademas por lo que pude entender del articulo, MVC va mas allá de las 3 capas (entidad,logica,datos) todas estas conforman parte del Modelo en el mundo de MVC