El Patrón MVC es Obsoleto

En este video vamos a analizar el patrón arquitectónico MVC (Modelo, Vista, Controlador) y sus deficiencias a la hora de hacer proyectos escalables.

📚 Mis Libros

🤖 Mi Setup

#programación #dev #programming

[elazzote]

En plena clase de programación 2 arrancando el tema de MVC, mis alumnos llegan con la noticia que un youtuber famoso habia subido un video hace cuatro horas donde decia que "El Patrón MVC es Obsoleto", pero tu explicación me ha dejado bien parado💪, buen trabajo.

[tipo_deincognito]

Es un tema un tanto peliagudo. MVC como tal era un modelo (un patrón en realidad) para organizar el comportamiento de los datos (Model/Modelo: persistencia, reglas de negocio, datos...), UI (View/Vista: html templates, java swing...) y el comportamiento que los relaciona (Controller/Controlador: ) de pequeños componentes.

Esto queda más claro con un ejemplo, uno hiper simple podría ser: los datos y como se organizan y las reglas que cumplen correspondientes a un Select (Model), la UI correspondiente al Select (View), el comportamiento de como se relacionan dicho Model y View (Controller). Es decir, la View expondría al Usuario la forma de relacionarse con el Model (clicks, teclado...), el Controller sería el encargado de traducir lo que sucede en la View y como afecta al Model (y viceversa, trasladar cambios en el Model a la View) y el Model sería el encargado de tratar los datos (reglas de negocio, organizarlos...).

Es importante fijarse en un detalle: en el paper original no se hacía referencia a la persistencia como tal, que es con lo que sin duda se relaciona a día de hoy el Model. El modelo MVC era simplemente una forma de manejar el *estado* (Model) de las aplicaciones y mantenerlo en sincronía con la View a través de un código que controlase esos cambios (Controller).

Fue después cuando esa idea, se empezó a mezclar con una especie de arquitectura por capas, naciendo de ahí diferentes soluciones y propuestas. Una de las más interesantes, y que sirve de semilla para las "arquitecturas limpias" (Onion, Clean, Hexagonal...), fue la propuesta de Ivar Jacobson que vió la necesidad de generalizar y aplicar el concepto a un nivel mayor, a un nivel de *Arquitectura de Aplicación* (no lo llamó MVC) y consistía en una Arquitectura en Capas con: Capa de Presentación, Capa de Negocio y Capa de Acceso a Datos.

Posteriormente Jacobson introdujo el concepto de "Componentes de Control" (¿alguien ha dicho "ports", "adapters", "interface"...?) dónde se proponía que no solo la UI necesitaba una abstracción "View" si no que eso se podía aplicar a otras partes de una aplicación como... ¡el acceso a datos! Siendo DAO (Data Access Object) o Repository patrones que representaban una "View" de los datos, una abstracción, una interfaz, un "Adapter" si nos vamos a Hexagonal.

En realidad este concepto de "View" más general que después Cockburn llamó Adapters y que también tiene la Clean Architecture (y la Onion, etc) no es más que el resultado de aplicar OCP y Liskov a lo que ya había: OCP porque ofrece una forma de añadir comportamiento sin modificar el orginal (esta "View", este "Adapter", permite expandir la funcionaldiad del modelo, la vista, una API rest...) y además nos ayuda a "localizar" la afectación de los cambios de estas partes (si el modelo, la API, etc cambian, solo necesita cambiar mi "View", mi "Adapter" de estos elementos) y Liskov porque una vez tengo esto, si soy disciplinado y aplico Liskov, podré tener una abstracción intercambiable (si mañana necesito poder guardar y acceder a datos en Redis o MySQL dependiendo de la situación solamente necesito dos "View" del Modelo, una MySQL y otra Redis, que sean compatibles y que pueda decidir en tiempo de ejecución si uso una u otra, por ejemplo, o si quiero migrar de MySQL a Postgre, solamente necesito sustituir esa "View", ese "Adapter").

Y, desde luego, en ningún momento, ni el MVC orginal, ni Jacobson, prohiben que organices el código en más objetos, que es una interpretación de MVC un poco "tonta" y de "junior" (me han dado tres cajas, a ver en cual cabe esta línea). Desde el inicio un Controller podía usar múltiples funciones u objetos para realizar sus funciones, lo mismo el Model o la View... por dios, ¡si nació en Smalltalk! xD.

Pienso que es importante revisitar las bases y la historia de como sucedieron las cosas, me parece que hemos perdido por el camino conceptos de Ingeniería del Software muy asentados y muy concretos y los hemos cambiado por palabras más amables pero mucho más inespecíficas ("Adapter", "Ports", "Hexagonal", "Clean"...). Que están bien para entrar en el tema y acercar los conceptos pero que deben ser cambiadas por las más específicas una vez las comprendemos.

Menuda chapa que me ha salido...😅

[dantecortes]

Buen video, yo tengo 10 años programando en PHP y Laravel, al principio solo usaba traits para evitar la redundancia y despues vi mejor usar services para la logica de negocio, repositories para las consultas a las bd, requests para las validaciones, una capa api para consultas a apis de terceros, a parte del ya propuesto MVC que viene en la estructura de archivos para laravel, buen video, sigur asi Hector que tu conocimiento es oro puro, saludos desde Perú.

[JorgeMBallesterosJ]

Apuntado en Metalcode. A seguir aprendiendo del mejor. Gracias por compartir tu conocimiento. Saludos desde Colombia:)

[joseguerra]

Es verdad. Estuve desarrollando un sistema de gestion de ordenes de servicio que era bastante complejo y lo que dice hector es cierto. Terminabas con controladores que hacian un monton de cosas y peor, despues t dabas cuenta que ese monton de cosas tenias q hacerlas igual en otro controlador... entonces la cantidad de redundancia era ridicula.

Si bien es cierto que clean arquitecture lleva mas trabajo, de verdad te protege se todo esto y a la larga es mucho mas facil aunque parezca contradictorio. Aparte que con el autocompletado de copilot o de codeium (super recomendada esa ultima para vs code porque es gratis) realmente no tienes q escribir tanto codigo. Es saber como organizar las clases y como funciona la arquitura. Lo demas sale casi solo

[taikun]

Excelente video, y justamente los proyectos en los que he trabajado que tienen la base de MVC colocan por separado reglas de negocio y validaciones, asi como lo mencionas.

[TheIronmandi]

Siempre diciendo las cosas como son 🔥🔥

[luisgamarrarosado]

Muchas gracias!!! Que importante es explicar patrones de diseño con gráficos de mi parte es más digerible de esa manera

[Diego-xrbd]

Excelente video !! lo aplicaré en django

[marionaya]

Estoy estudiando un grado de 2 años de programación y estamos ahora con el MVC. La verdad que ahora mismo este vídeo se me queda grande y no he pillado más de la mitad de las cosas, pero volveré aquí algún día porque entiendo que aporta valor y me será útil cuando empiece con proyectos más grandes.

[luisu]

Muchas gracias cabezon, ta bueno el video. Ahora haz uno de Blazor sobre los RenderMode

[fabianromero]

Muy interesante, muchas gracias por compartir el conocimiento

[alexanderhernandez]

Excelente explicacion saludos desde El Salvador❤

[saboresimprovisados]

Apenas aprendi a hacer proyectos con el MVC y lo de las validaciones en todos los controladoras me tenian nervioso porque pensaba que era mejor separar las validaciones de TODO y solo implementarlas en la controladora cuando se requiera. Me lo acabas de confirmar jajaja

[el_migue_dev]

Excelente video!! No siempre se ve contenido de estos temas por youtube :P
Estoy de acuerdo en que MVC no es la solucion a todos nuestro problemas y que no siempre es aplicable tal cual como es (como casi todo en desarrollo de software).
En mi caso, suelo usar mucho el modelo de IDD que propone Sandro Mancuso (con alguna que otra variación), en donde los casos de uso se mapean como "Acciones" dentro del sistema (como una capa de logica de negocio). Y luego separar los repositorios que utlizamos, utiliazndo siempre inyeccion de dependencias para poder desacoplar nuestras clases.

[pabloguillermoalarcon]

Jaja me encanta siempre como empiezas tus videos hdeleon, ademas tu contenido lo considero muy valioso. Simplemente gracias.

[kevin]

Justo estoy intentando hacer testing el siguiente video para hcer testing sin importar el framework ademas de este, me serviran, muchas gracias por tu conocimiento

[rutx]

Para un proyecto mediano en Angular 16 que arquitectura recomendarias?

[jeovannynava]

Gracias por el video. Estoy por empezar un proyecto grande y necesitaba utilizar MVC porque necesito el razor pero al mismo tiempo quería usar clean architecture, esta alternativa me parece fenomenal

[felipecruz]

buena explicación, esperaba una sugerencia de patron de arquitectura jajaj saludos