Model-View-Controller est-il mort sur le front-end?

De plus en plus de développeurs front-end adoptent des architectures unidirectionnelles. Alors, quel est l'avenir de l'approche classique Model-View-Controller (MVC)?

Afin de comprendre comment nous en sommes arrivés à ce point, examinons d'abord l'évolution de l'architecture front-end.

Au cours des quatre dernières années, j'ai travaillé sur de nombreux projets Web et passé beaucoup de temps à concevoir des frontaux et à y intégrer des frameworks.

Avant 2010, JavaScript - dans lequel le langage de programmation jQuery était écrit - était principalement utilisé pour ajouter la manipulation DOM aux sites Web traditionnels. Les développeurs ne semblaient pas se soucier beaucoup de l'architecture elle-même. Des choses comme le modèle de module révélateur étaient assez bonnes pour structurer nos bases de code autour.

Notre discussion actuelle sur l'architecture front-end vs back-end n'a eu lieu qu'à la fin de 2010. C'est à ce moment-là que les développeurs ont commencé à prendre au sérieux le concept d'une application à page unique . C'est également à ce moment que des frameworks comme Backbone et Knockout ont commencé à devenir populaires.

Étant donné que bon nombre des principes autour desquels ces cadres ont été construits étaient assez nouveaux à l'époque, leurs concepteurs ont dû chercher l'inspiration ailleurs. Ils ont emprunté des pratiques déjà bien établies pour l'architecture côté serveur. Et à ce moment-là, tous les frameworks côté serveur populaires impliquaient une sorte d'implémentation du modèle MVC classique (également connu sous le nom de MV * en raison de ses variations).

Lorsque React.js a été introduit pour la première fois en tant que bibliothèque de rendu, de nombreux développeurs se sont moqués de lui car ils considéraient sa manière de traiter le HTML dans JavaScript comme contre-intuitive. Mais ils ont négligé la contribution la plus importante apportée par React: l' architecture basée sur les composants .

React n'a pas inventé de composants, mais il a poussé cette idée encore plus loin.

Cette avancée majeure dans l'architecture a été ignorée même par Facebook, quand ils ont annoncé React comme le «V dans le MVC».

D'un autre côté, j'ai encore des cauchemars après avoir examiné une base de code dans laquelle Angular 1.x et React fonctionnaient ensemble.

2015 nous a apporté un changement majeur de mentalité - du modèle MVC familier aux architectures unidirectionnelles et aux flux de données dérivés de Flux et de la programmation réactive fonctionnelle, pris en charge par des outils comme Redux ou RxJS.

Alors, où est-ce que tout s'est mal passé pour MVC?

MVC reste probablement le meilleur moyen de gérer le côté serveur. Les cadres comme Rails et Django sont un plaisir de travailler avec.

Les problèmes proviennent du fait que les principes et les séparations introduits par MVC sur le serveur ne sont pas les mêmes que sur le client.

Couplage contrôleur-vue

Vous trouverez ci-dessous un diagramme de la façon dont la vue et le contrôleur interagissent sur le serveur. Il n'y a que deux points de contact entre eux, tous deux traversant la frontière entre le client et le serveur.

Lorsque vous passez à MVC sur le client, il y a un problème. Les contrôleurs ressemblent à ce que nous appelons «code-behind». Le contrôleur dépend fortement de la vue. Dans la plupart des implémentations de framework, il est même créé par la vue (comme c'est le cas, par exemple, avec ng-controller dans Angular).

De plus, lorsque vous pensez au principe de responsabilité unique, cela enfreint clairement les règles. Le code du contrôleur client traite à la fois de la gestion des événements et de la logique métier , à un certain niveau.

Modèles gras

Pensez un peu au type de données que vous stockez dans un modèle côté client.

D'une part, vous avez des données telles que les utilisateurs et les produits , qui représentent l'état de votre application . D'autre part, vous devez stocker l' état de l' interface utilisateur - des éléments tels que showTab ou selectedValue .

À l'instar du contrôleur, le modèle enfreint le principe de responsabilité unique, car vous ne disposez pas d'un moyen distinct de gérer l' état de l'interface utilisateur et l' état de l'application .

Alors, où s'insèrent les composants dans ce modèle?

Les composants sont: Vues + Gestion des événements + État de l'interface utilisateur .

Le diagramme ci-dessous montre comment vous divisez réellement le modèle MVC d'origine pour obtenir les composants. Ce qui reste au-dessus de la ligne, c'est exactement ce que Flux tente de résoudre: gérer l' état de l'application et la logique métier .

Avec la popularité de React et de l' architecture basée sur les composants , nous avons vu l'essor des architectures unidirectionnelles pour la gestion de l'état des applications.

L'une des raisons pour lesquelles ces deux éléments vont si bien ensemble est qu'ils couvrent entièrement l'approche MVC classique. Ils offrent également une bien meilleure séparation des préoccupations lorsqu'il s'agit de créer des architectures frontales.

Mais ce n'est plus une histoire de React. Si vous regardez Angular 2, vous verrez exactement le même modèle appliqué, même si vous avez différentes options pour gérer l'état de l'application comme ngrx / store.

Il n'y avait vraiment rien que MVC aurait pu faire mieux sur le client. Il était voué à l'échec depuis le début. Nous avions juste besoin de temps pour voir cela. Grâce à ce processus de cinq ans, l'architecture frontale a évolué pour devenir ce qu'elle est aujourd'hui. Et quand on y pense, cinq ans, ce n'est pas si long pour que les meilleures pratiques émergent.

MVC était nécessaire au début car nos applications frontales devenaient de plus en plus volumineuses et complexes, et nous ne savions pas comment les structurer. Je pense que cela a atteint son objectif, tout en fournissant une bonne leçon sur la prise d'une bonne pratique d'un contexte (le serveur) et son application à un autre (le client).

Alors, que nous réserve l'avenir?

Je ne pense pas que nous reviendrons de sitôt à l'architecture MVC classique pour nos applications frontales.

Alors que de plus en plus de développeurs commencent à voir les avantages des composants et des architectures unidirectionnelles, l'accent sera mis sur la création de meilleurs outils et bibliothèques qui suivent cette voie.

Ce type d'architecture sera-t-il la meilleure solution dans cinq ans? Il y a de bonnes chances que cela se produise, mais là encore, rien n'est certain.

Il y a cinq ans, personne n'aurait pu prédire comment nous finirions par écrire des applications aujourd'hui. Je ne pense donc pas qu'il soit sûr de parier pour l'avenir maintenant.

C'est à peu près ça! J'espère que vous avez aimé lire ceci. J'apprécie vos commentaires ci-dessous.

Si vous avez aimé l'article, cliquez sur le cœur vert ci-dessous et je saurai que mes efforts ne sont pas vains.