Buenas tardes lectores, el otro día estaba pensando a razón de (creo) una charla que tuve con un amigo y me cuestioné la utilidad de este patrón de diseño MVC, ya que resulta que suele ser el as bajo la manga de cualquier programador en php para decir que su código responde a un patrón que le asegura la robustez, esta entrada fue escrita para mi blog el cual les propongo visitar para ver entradas de este tipo.
Desde ya que decir que el patrón mvc asegura la robustez en un código es una falacia, mvc aplicado a la web es una total mentira y ahora explicaremos el porqué de esto.
La realidad es que éste patrón no puede ser aplicado a la web como lo es hoy en día la web, ya que MVC fue diseñado para resolver otro problema, está pensado para aplicaciones estáticas como las aplicaciones de escritorio, piensa entonces en un programa común y corriente, con muchos botones, que cuando le haces click a alguno estás ejecutando uno de los tantos controladores, y su respectivo modelo y obteniendo una actualización del estado del botón basado en la vista.
Entonces ¿qué podemos concluir? Que mvc fue diseñado para resolver una problemática que responde a la situación en la cual se tienen muchos puntos de entrada y muchos puntos de salida, y para solucionarlo se implementó esta forma de trabajo, pero si pensamos en la web en realidad no funciona ni por casualidad de esta forma, la web tiene una sola entrada que es la request y una sola salida response, entonces, volvamos a analizar esto, si mvc fue diseñado para resolver el problema de simultaneidad que ocurre en entornos de multiples entradas y salidas, pero la web no funciona así, entonces que alguien me explique qué es lo ¿Que en realidad está resolviendo mvc?
Dejo a continuación la implementación original:
The viewmanages 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).
Entonces volviendo al tema, que es lo ¿Qué estamos haciendo con mvc?, ¿Para qué lo usamos? Quizá la única utilidad que tendría mvc es acostumbrar a los programadores que crean código mezclando javascript+html+etiquetas php a separar la parte visual de la parte de código de aplicación de la parte de código de bases de datos, pero… ¿Realmente mvc está ayudando?
Originalmente si programas a lo bruto mezclas todo y generalmente ejecutas un archivo que hace todo lo necesario para responder la petición, con mvc por el contrario, empiezas a cargar una serie de cosas que es probable que no necesites, pero vienen con la estructura del modelo, con la estructura del controlador, para luego poder utilizar solo una partecita de cada uno de estos, y devolver el resultado, y borrar todo lo construido, a la próxima petición ¿que haremos? Simple, volvemos a cargar tooodas las funciones del controlador, y todas las del modelo, para simplemente usar una o dos de cada uno, y así sucesivamente.
Si bien el patrón mvc deja un código más “claro” y entendible o mejor dicho más ordenado, aumenta la carga de cosas y disminuye el rendimiento, pero esperen eso no es todo, el gran problema de programar es la escala, las personas creemos que todo es escalable, si funciona a pequeña escala funcionará a gran escala, y esto es un error fatal, por la disposición de la web y su forma de funcionar, y dado que mvc estaba pensado para otro tipo de problemas y situaciones, en realidad cuanto más grande sea nuestro sistema más grande y problemático será mvc, y menos eficiente.
Concluimos entonces que mvc no solo no resuelve ningún problema sino que en grandes sistemas genera un gran posible problema, y para lo único que se usa mvc es para ordenar un poco las partes del código.
Un saludo! Y espero les haya gustado.
std_io
