Ar „Model-View-Controller“ yra negyvas priekyje?

Vis daugiau front-end kūrėjų taiko vienakryptes architektūras. Taigi, kokia yra klasikinio „Model-View-Controller“ (MVC) požiūrio ateitis?

Norėdami suprasti, kaip mes pasiekėme šį tašką, pirmiausia apžvelkime front-end architektūros evoliuciją.

Per pastaruosius ketverius metus dirbau su daugybe internetinių projektų ir praleidau daug laiko, projektuodamas sąsajas ir integruodamas į jas sistemas.

Iki 2010 m. „ JavaScript“ - ta programavimo kalba „ jQuery“ parašyta - daugiausia buvo naudojama DOM manipuliacijoms pridėti prie tradicinių svetainių. Panašu, kad kūrėjams nelabai rūpėjo pati architektūra. Tokie dalykai, kaip atskleidžiantis modulio modelis, buvo pakankamai geri, kad struktūrizuotų mūsų kodų bazes.

Dabartinė diskusija apie „front-end“ ir „back-end“ architektūrą kilo tik 2010 m. Pabaigoje. Tada kūrėjai pradėjo rimtai vertinti vieno puslapio programos koncepciją . Taip pat tada, kai tokios sistemos kaip „Backbone“ ir „Knockout“ pradėjo populiarėti.

Kadangi daugelis principų, kuriais buvo grindžiamos šios sistemos, tuo metu buvo gana nauji, jų dizaineriai turėjo ieškoti įkvėpimo kitur. Jie pasiskolino praktiką, kuri jau buvo gerai sukurta serverio pusės architektūrai. Tuo metu visos populiarios serverio sistemos struktūros turėjo tam tikrą klasikinio MVC modelio (dėl savo variantų dar vadinamo MV *) įgyvendinimą.

Kai „React.js“ pirmą kartą buvo pristatyta kaip atvaizdavimo biblioteka, daugelis kūrėjų iš jos tyčiojosi, nes suvokė, kad jos būdas valdyti HTML „JavaScript“ yra intuityvus. Tačiau jie nepastebėjo svarbiausio „React“ indėlio - komponentais paremtos architektūros .

„React“ nesugalvojo komponentų, tačiau žengė šią idėją dar vienu žingsniu.

Šio svarbiausio architektūros proveržio nepastebėjo net „Facebook“, kai jie „React“ reklamavo kaip „V MVC“.

Pažymėtina, kad vis dar sapnuoju košmarus, peržiūrėjęs kodų bazę, kurioje kartu veikė ir „Angular 1.x“, ir „React“.

2015 m. Mąstysena labai pasikeitė - nuo įprasto MVC modelio iki vienakryptės architektūros ir duomenų srautų, gautų iš srauto ir funkcinio reaktyvaus programavimo, palaikomų tokių įrankių kaip „Redux“ ar „RxJS“.

Taigi, kur viskas klostėsi MVC?

MVC vis dar yra geriausias būdas susidoroti su serverio puse. Su tokiais rėmais kaip „Rails“ ir „Django“ malonu dirbti.

Problemos kyla dėl to, kad principai ir atskyrimai, kuriuos MVC įdiegė serveryje, nėra tokie patys kaip kliento.

Valdiklio ir vaizdo sujungimas

Žemiau pateikiama schema, kaip „View“ ir valdiklis sąveikauja serveryje. Tarp jų yra tik du sąlyčio taškai, abu kertantys ribą tarp kliento ir serverio.

Kai pereinate į kliento MVC, kyla problema. Valdikliai panašūs į tai, ką mes vadiname „už kodo“. Valdiklis labai priklauso nuo Vaizdo. Daugumoje pagrindų diegimų jį netgi sukuria „View“ (kaip yra, pavyzdžiui, „ng-controller“ kampe).

Be to, pagalvojus apie bendros atsakomybės principą, tai akivaizdžiai pažeidžia taisykles. Kliento valdiklio kodas susijęs su įvykių tvarkymu ir verslo logika tam tikru lygiu.

Riebalų modeliai

Pagalvokite apie tai, kokius duomenis kliento pusėje saugote modelyje.

Viena vertus, turite duomenų, pvz., Naudotojų ir produktų , kurie atspindi jūsų programos būseną . Kita vertus, turite išsaugoti vartotojo sąsajos būseną - tokius dalykus kaip „ showTab“ arba „ selectedValue“ .

Panašiai kaip valdiklis, modelis pažeidžia vienos atsakomybės principą, nes jūs neturite atskiro vartotojo sąsajos ir programos būsenos valdymo būdų .

Taigi, kur komponentai tinka šiam modeliui?

Komponentai yra: Rodiniai + Įvykių tvarkymas + NS būsena .

Žemiau pateiktoje diagramoje parodyta, kaip iš tikrųjų padalijote originalų MVC modelį, kad gautumėte komponentus. Liko būtent tai, ką „ Flux “ bando išspręsti: „ Application State“ ir „ Business Logic“ valdymas .

Populiarėjant „React“ ir komponentų pagrindu sukurtai architektūrai , matėme vienkryptės architektūros valdymą programos būsenai valdyti.

Viena iš priežasčių, kodėl šie du taip gerai dera, yra ta, kad jie visiškai aprėpia klasikinį MVC metodą. Jie taip pat leidžia kur kas geriau atskirti rūpesčius kuriant front-end architektūras.

Bet tai jau ne „React“ istorija. Jei pažvelgsite į „Angular 2“, pamatysite tą patį modelį, net jei turite skirtingų galimybių valdyti programos būseną, pvz., „Ngrx / store“.

Iš tikrųjų nebuvo nieko, ką MVC būtų galėjęs padaryti geriau klientui. Nuo pat pradžių buvo pasmerkta žlugti. Mums tiesiog reikėjo laiko tai pamatyti. Per šį penkerių metų procesą front-end architektūra tapo tokia, kokia yra šiandien. Gerai pagalvojus, penkeri metai nėra toks ilgas laikas, kad atsirastų geriausios praktikos pavyzdžiai.

MVC pradžioje buvo reikalinga, nes mūsų priekinės programos buvo vis didesnės ir sudėtingesnės, ir mes nežinojome, kaip jas struktūrizuoti. Manau, kad jis atitiko savo tikslą, kartu suteikdamas gerą pamoką apie geros praktikos perėmimą iš vieno konteksto (serverio) ir pritaikymą kitam (klientui).

Taigi, kokia ateitis?

Nemanau, kad greitai grįšime prie klasikinės MVC architektūros, naudodamiesi savo priekinės programos programomis.

Kai vis daugiau kūrėjų pradeda suprasti komponentų ir vienakryptės architektūros pranašumus, dėmesys bus sutelktas į geresnių įrankių ir bibliotekų, einančių tuo keliu, kūrimą.

Ar tokia architektūra bus geriausias sprendimas po penkerių metų? Yra nemaža tikimybė, kad taip nutiks, bet vėlgi, niekas nėra tikras.

Prieš penkerius metus niekas negalėjo numatyti, kaip šiandien galų gale rašysime programas. Taigi nemanau, kad dabar yra saugu lažintis dėl ateities.

Viskas apie tai! Tikiuosi, kad jums patiko tai skaityti. Džiaugiuosi jūsų atsiliepimais žemiau.

Jei jums patiko straipsnis, spustelėkite žemiau esančią žalią širdį ir žinosiu, kad mano pastangos nėra veltui.