Er Model-View-Controller død i frontenden?

Flere og flere frontend-udviklere vedtager envejsarkitekturer. Så hvad er fremtiden for den klassiske Model-View-Controller (MVC) tilgang?

For at forstå, hvordan vi kom til dette punkt, lad os først gennemgå udviklingen af ​​frontend-arkitektur.

I løbet af de sidste fire år har jeg arbejdet på en lang række webprojekter og brugt en god tid på at arkitektere frontenderne og integrere rammer i dem.

Før 2010 blev JavaScript - det programmeringssprog, jQuery blev skrevet i - hovedsagelig brugt til at tilføje DOM-manipulation til traditionelle websteder. Udviklere syntes ikke at bryde sig meget om selve arkitekturen. Ting som det afslørende modulmønster var gode nok til at strukturere vores kodebaser rundt omkring.

Vores aktuelle diskussion af front-end vs back-end-arkitektur opstod først i slutningen af ​​2010. Det var da udviklere begyndte at tage begrebet en enkelt sideapplikation alvorligt. Dette er også, når rammer som Backbone og Knockout begyndte at blive populære.

Da mange af de principper, som disse rammer blev bygget omkring, var ret nye på det tidspunkt, måtte deres designere søge inspiration andetsteds. De lånte praksis, der allerede var veletableret til serversides arkitektur. Og i det øjeblik involverede alle de populære serverrammer en slags implementering af den klassiske MVC-model (også kendt som MV * på grund af dens variationer).

Da React.js først blev introduceret som et gengivelsesbibliotek, spottede mange udviklere det, fordi de opfattede sin måde at håndtere HTML i JavaScript på som kontraintuitivt. Men de overså det vigtigste bidrag, som React bragte på bordet - komponentbaseret arkitektur .

React opfandt ikke komponenter, men det tog denne idé et skridt videre.

Dette store gennembrud i arkitektur blev overset selv af Facebook, da de annoncerede React som "V i MVC."

På en sidebemærkning har jeg stadig mareridt efter at have gennemgået en codebase, der både havde Angular 1.x og React, der arbejder sammen.

2015 bragt os et stort skift i tankegang - fra det velkendte MVC mønster til ensrettet arkitekturer og datastrømme stammer fra Flux og Funktionel Reaktiv Programmering, støttet af værktøjer som Redux eller RxJS.

Så hvor gik det hele galt for MVC?

MVC er stadig sandsynligvis den bedste måde at håndtere serversiden på. Rammer som Rails og Django er en fornøjelse at arbejde med.

Problemerne skyldes, at de principper og separationer, som MVC introducerede på serveren, ikke er de samme som på klienten.

Controller-View kobling

Nedenfor er et diagram over, hvordan visningen og controlleren interagerer på serveren. Der er kun to berøringspunkter mellem dem, begge krydser grænsen mellem klienten og serveren.

Når du flytter til MVC på klienten, er der et problem. Controllers ligner det, vi kalder "kode bag." Controlleren er meget afhængig af visningen. I de fleste rammeimplementeringer oprettes det endda af View (som det er tilfældet med for eksempel ng-controller i Angular).

Når du tænker på princippet om et enkelt ansvar, bryder dette desuden klart reglerne. Klientcontroller-koden beskæftiger sig med både hændelseshåndtering og forretningslogik på et bestemt niveau.

Fat Modeller

Tænk lidt over, hvilken type data du gemmer i en model på klientsiden.

På den ene side har du data som brugere og produkter , der repræsenterer din applikationstilstand . På den anden side skal du gemme brugergrænsefladen - ting som showTab eller selectedValue .

I lighed med controlleren bryder modellen det enkelte ansvarsprincip, fordi du ikke har en separat måde at administrere brugergrænsefladen og applikationsstaten på .

Så hvor passer komponenter ind i denne model?

Komponenterne er: Views + Event Handling + UI State .

Diagrammet nedenfor viser, hvordan du faktisk deler den originale MVC-model for at få komponenterne. Hvad der er tilbage over linjen er nøjagtigt hvad Flux forsøger at løse: styring af Application State og Business Logic .

Med populariteten af ​​React og komponentbaseret arkitektur så vi stigningen i envejsarkitekturer til styring af applikationstilstand.

En af grundene til, at disse to går så godt sammen så godt, er at de dækker den klassiske MVC-tilgang helt. De giver også en meget bedre adskillelse af bekymringer, når det kommer til at bygge frontend-arkitekturer.

Men dette er ikke længere en React-historie. Hvis du ser på Angular 2, vil du se det nøjagtige samme mønster, der anvendes, selvom du har forskellige muligheder for at administrere applikationstilstand som ngrx / store.

Der var ikke rigtig noget MVC kunne have gjort bedre for klienten. Det var dømt til at mislykkes fra starten. Vi havde bare brug for tid til at se dette. Gennem denne femårige proces udviklede frontend-arkitektur sig til, hvad den er i dag. Og når du tænker over det, er fem år ikke så lang tid for bedste praksis at dukke op.

MVC var nødvendigt i starten, fordi vores frontend-applikationer blev større og mere komplekse, og vi vidste ikke, hvordan vi skulle strukturere dem. Jeg synes, det tjente sit formål, samtidig med at det gav en god lektion om at tage en god praksis fra en kontekst (serveren) og anvende den til en anden (klienten).

Så hvad har fremtiden?

Jeg tror ikke, at vi snart kommer tilbage til den klassiske MVC-arkitektur til vores frontend-apps.

Da flere og flere udviklere begynder at se fordelene ved komponenter og envejsarkitekturer, vil fokus være på at opbygge bedre værktøjer og biblioteker, der går den vej.

Vil denne form for arkitektur være den bedste løsning om fem år? Der er en god chance for, at det sker, men så er der intet sikkert.

For fem år siden kunne ingen have forudsagt, hvordan vi ender med at skrive apps i dag. Så jeg tror ikke, det er sikkert at placere væddemål for fremtiden nu.

Det handler om det! Jeg håber du nød at læse dette. Jeg glæder mig over din feedback nedenfor.

Hvis du kunne lide artiklen, skal du klikke på det grønne hjerte nedenfor, og jeg ved, at min indsats ikke er forgæves.