¿Model-View-Controller está muerto en la interfaz?

Cada vez más desarrolladores front-end están adoptando arquitecturas unidireccionales. Entonces, ¿cuál es el futuro del enfoque clásico Modelo-Vista-Controlador (MVC)?

Para entender cómo llegamos a este punto, revisemos primero la evolución de la arquitectura de front-end.

Durante los últimos cuatro años, trabajé en una gran cantidad de proyectos web y pasé una buena cantidad de tiempo diseñando interfaces e integrando marcos en ellas.

Antes de 2010, JavaScript , ese lenguaje de programación en el que se escribió jQuery , se usaba principalmente para agregar manipulación DOM a sitios web tradicionales. A los desarrolladores no parecía importarles mucho la arquitectura en sí. Cosas como el patrón de módulo revelador fueron lo suficientemente buenas como para estructurar nuestras bases de código.

Nuestra discusión actual sobre la arquitectura front-end vs back-end se produjo a finales de 2010. Aquí es cuando los desarrolladores comenzaron a tomar en serio el concepto de una aplicación de una sola página . Aquí es también cuando los frameworks como Backbone y Knockout comenzaron a hacerse populares.

Dado que muchos de los principios sobre los que se construyeron estos marcos eran bastante nuevos en ese momento, sus diseñadores tuvieron que buscar inspiración en otros lugares. Tomaron prestadas prácticas que ya estaban bien establecidas para la arquitectura del lado del servidor. Y en ese momento, todos los frameworks populares del lado del servidor involucraban algún tipo de implementación del modelo MVC clásico (también conocido como MV * debido a sus variaciones).

Cuando React.js se introdujo por primera vez como una biblioteca de renderizado, muchos desarrolladores se burlaron de él porque percibieron su forma de tratar con HTML en JavaScript como contraintuitiva. Pero pasaron por alto la contribución más importante que React trajo sobre la mesa: la arquitectura basada en componentes .

React no inventó componentes, pero llevó esta idea un paso más allá.

Este gran avance en la arquitectura fue pasado por alto incluso por Facebook, cuando anunciaron React como la "V en el MVC".

En una nota al margen, todavía tengo pesadillas después de revisar una base de código que tenía Angular 1.xy React trabajando juntos.

2015 nos trajo un cambio importante en la mentalidad: del patrón MVC familiar a las arquitecturas unidireccionales y los flujos de datos derivados de Flux y la programación reactiva funcional, compatibles con herramientas como Redux o RxJS.

Entonces, ¿dónde le salió todo mal a MVC?

MVC sigue siendo probablemente la mejor manera de lidiar con el lado del servidor. Es un placer trabajar con Frameworks como Rails y Django.

Los problemas surgen del hecho de que los principios y separaciones que MVC introdujo en el servidor no son los mismos que en el cliente.

Acoplamiento de vista de controlador

A continuación se muestra un diagrama de cómo interactúan la Vista y el Controlador en el servidor. Solo hay dos puntos de contacto entre ellos, ambos cruzan el límite entre el cliente y el servidor.

Cuando pasa a MVC en el cliente, hay un problema. Los controladores se parecen a lo que llamamos "código subyacente". El controlador depende en gran medida de la vista. En la mayoría de las implementaciones de framework, incluso es creado por View (como es el caso, por ejemplo, con ng-controller en Angular).

Además, cuando piensa en el Principio de Responsabilidad Única, esto claramente está rompiendo las reglas. El código del controlador del cliente se ocupa tanto del manejo de eventos como de la lógica empresarial , en un cierto nivel.

Modelos gordos

Piense un poco en el tipo de datos que almacena en un modelo en el lado del cliente.

Por un lado, tiene datos como usuarios y productos , que representan el estado de su aplicación . Por otro lado, debe almacenar el estado de la interfaz de usuario, como showTab o selectedValue .

Al igual que el controlador, el modelo rompe el principio de responsabilidad única, porque no tiene una forma separada de administrar el estado de la interfaz de usuario y el estado de la aplicación .

Entonces, ¿dónde encajan los componentes en este modelo?

Los componentes son: Vistas + Gestión de eventos + Estado de la interfaz de usuario .

El siguiente diagrama muestra cómo dividió realmente el modelo MVC original para obtener los componentes. Lo que queda por encima de la línea es exactamente lo que Flux está tratando de resolver: administrar el estado de la aplicación y la lógica comercial .

Con la popularidad de React y la arquitectura basada en componentes , vimos el surgimiento de arquitecturas unidireccionales para administrar el estado de la aplicación.

Una de las razones por las que estos dos van tan bien juntos es que cubren por completo el enfoque clásico de MVC. También proporcionan una separación mucho mejor de preocupaciones cuando se trata de construir arquitecturas de front-end.

Pero esta ya no es una historia de React. Si observa Angular 2, verá que se aplica exactamente el mismo patrón, aunque tiene diferentes opciones para administrar el estado de la aplicación como ngrx / store.

Realmente no había nada que MVC pudiera haber hecho mejor en el cliente. Estaba condenado al fracaso desde el principio. Solo necesitábamos tiempo para ver esto. A través de este proceso de cinco años, la arquitectura front-end evolucionó hasta convertirse en lo que es hoy. Y cuando lo piensas, cinco años no es tanto tiempo para que surjan las mejores prácticas.

MVC era necesario al principio porque nuestras aplicaciones frontales eran cada vez más grandes y complejas, y no sabíamos cómo estructurarlas. Creo que cumplió su propósito, al mismo tiempo que brinda una buena lección sobre cómo tomar una buena práctica de un contexto (el servidor) y aplicarla a otro (el cliente).

Entonces, ¿qué nos depara el futuro?

No creo que volvamos a la arquitectura MVC clásica en el corto plazo para nuestras aplicaciones frontales.

A medida que más y más desarrolladores comiencen a ver las ventajas de los componentes y las arquitecturas unidireccionales, la atención se centrará en crear mejores herramientas y bibliotecas que sigan ese camino.

¿Será este tipo de arquitectura la mejor solución dentro de cinco años? Hay muchas posibilidades de que eso suceda, pero, de nuevo, nada es seguro.

Hace cinco años, nadie podría haber predicho cómo terminaríamos escribiendo aplicaciones hoy. Así que no creo que sea seguro hacer ahora las apuestas para el futuro.

¡Eso es todo! Espero que hayas disfrutado leyendo esto. Agradezco sus comentarios a continuación.

Si le gustó el artículo, haga clic en el corazón verde a continuación y sabré que mis esfuerzos no son en vano.