Vai Model-View-Controller priekšējā galā ir miris?

Arvien vairāk front-end izstrādātāju izmanto vienvirziena arhitektūras. Tātad, kāda ir klasiskās modeļa skata-kontroliera (MVC) pieejas nākotne?

Lai saprastu, kā mēs nonācām līdz šim brīdim, vispirms pārskatīsim front-end arhitektūras attīstību.

Pēdējo četru gadu laikā esmu strādājis pie daudziem tīmekļa projektiem un pavadījis daudz laika, veidojot priekšējos galus un integrējot tajos ietvaru.

Pirms 2010. gada JavaScript - programmatūras valodas jQuery rakstīšana - galvenokārt tika izmantots, lai pievienotu DOM manipulācijas tradicionālajām vietnēm. Izskatījās, ka izstrādātājiem nav lielas nozīmes par pašu arhitektūru. Tādas lietas kā atklājošais moduļu modelis bija pietiekami labas, lai strukturētu mūsu koda bāzes.

Mūsu pašreizējā diskusija par front-end un back-end arhitektūru notika tikai 2010. gada beigās. Tas bija tad, kad izstrādātāji sāka nopietni uztvert vienas lapas lietojumprogrammas koncepciju . Tas ir arī tad, kad tādi ietvari kā Backbone un Knockout sāka kļūt populāri.

Tā kā daudzi principi, uz kuriem šie ietvari tika veidoti, tajā laikā bija diezgan jauni, to dizaineriem vajadzēja meklēt iedvesmu citur. Viņi aizņēmās praksi, kas jau bija labi izveidota servera puses arhitektūrai. Un tajā brīdī visas populārās servera puses ietvarstruktūras ietvēra sava veida klasiskā MVC modeļa ieviešanu (tā variāciju dēļ pazīstams arī kā MV *).

Kad React.js pirmo reizi tika ieviests kā atveidošanas bibliotēka, daudzi izstrādātāji par to ņirgājās, jo uzskatīja, ka tā veids, kā rīkoties ar HTML JavaScript valodā, ir pret intuitīvu. Bet viņi neņēma vērā vissvarīgāko ieguldījumu, ko React sniedza uz galda - uz komponentiem balstītu arhitektūru .

React neizgudroja komponentus, taču šo ideju spēra soli tālāk.

Šo lielo sasniegumu arhitektūrā nepamanīja pat Facebook, kad viņi reklamēja React kā “V MVC”.

Sānu piezīme: man joprojām ir murgi pēc koda bāzes pārskatīšanas, kurā gan Angular 1.x, gan React darbojas kopā.

2015. gads radīja mums būtiskas domāšanas maiņas - no pazīstamā MVC modeļa uz vienvirziena arhitektūru un datu plūsmām, kas iegūtas no plūsmas un funkcionālās reaktīvās programmēšanas, ko atbalsta tādi rīki kā Redux vai RxJS.

Tātad, kur tas viss ir kļūdījies MVC?

Iespējams, MVC joprojām ir labākais veids, kā tikt galā ar servera pusi. Ar tādiem ietvariem kā Rails un Django ir prieks strādāt.

Problēmas rodas no tā, ka MVC serverī ieviestie principi un atdalījumi nav tādi paši kā klientam.

Vadītāja un skata savienojums

Zemāk ir diagramma, kā skats un kontrolieris mijiedarbojas serverī. Starp tiem ir tikai divi saskares punkti, abi pārkāpjot robežu starp klientu un serveri.

Pārejot uz klienta MVC, rodas problēma. Kontrolieri atgādina to, ko mēs saucam par “kodētu”. Kontrolieris ir ļoti atkarīgs no skata. Lielākajā daļā ietvarstruktūru to pat izveido skats (kā tas notiek, piemēram, ar ng-controller in Angular).

Turklāt, domājot par vienotās atbildības principu, tas nepārprotami pārkāpj noteikumus. Klienta kontroliera kods ir saistīts gan ar notikumu apstrādi, gan ar biznesa loģiku noteiktā līmenī.

Tauku modeļi

Padomājiet mazliet par to, kāda veida datus klienta pusē glabājat modelī.

No vienas puses, jums ir tādi dati kā lietotāji un produkti , kas pārstāv jūsu lietojumprogrammas stāvokli . No otras puses, jums ir jāsaglabā UI stāvoklis - tādas lietas kā showTab vai selectedValue .

Līdzīgi kā kontrolieris, modelis pārkāpj vienotās atbildības principu, jo jums nav atsevišķa veida, kā pārvaldīt lietotāja saskarnes un lietojumprogrammas stāvokli .

Tātad, kur komponenti iekļaujas šajā modelī?

Komponenti ir: skati + notikumu apstrāde + lietotāja saskarnes statuss .

Zemāk redzamā diagramma parāda, kā jūs faktiski sadalījāt sākotnējo MVC modeli, lai iegūtu komponentus. Virs līnijas ir palicis tieši tas, ko Flux mēģina atrisināt: lietojumprogrammas stāvokļa un biznesa loģikas pārvaldība .

Ar React un komponentu bāzes arhitektūras popularitāti mēs redzējām vienvirziena arhitektūras pieaugumu lietojumprogrammu stāvokļa pārvaldībai.

Viens no iemesliem, kāpēc šie abi tik labi sader kopā, ir tas, ka tie pilnībā aptver klasisko MVC pieeju. Tie arī nodrošina daudz labāku problēmu atdalīšanu, kad tiek veidotas priekšējās daļas arhitektūras.

Bet tas vairs nav React stāsts. Ja paskatās uz Angular 2, redzēsiet, ka tiek izmantots tieši tāds pats modelis, lai gan jums ir dažādas iespējas pārvaldīt lietojumprogrammas stāvokli, piemēram, ngrx / store.

Nebija īsti nekā, ko MVC būtu varējis darīt labāk klientam. Jau no paša sākuma bija lemts izgāzties. Mums vajadzēja tikai laiku, lai to redzētu. Izmantojot šo piecu gadu procesu, front-end arhitektūra pārtapa par tādu, kāda tā ir šodien. Un, domājot par to, pieci gadi nav tik ilgs laiks, lai parādītos paraugprakse.

MVC sākumā bija nepieciešams, jo mūsu priekšējās programmas kļuva arvien lielākas un sarežģītākas, un mēs nezinājām, kā tās strukturēt. Es domāju, ka tas kalpoja savam mērķim, vienlaikus sniedzot labu mācību par labas prakses pārņemšanu no viena konteksta (servera) un piemērošanu citam (klientam).

Tātad, kāda ir nākotne?

Es nedomāju, ka mēs drīz atgriezīsimies pie klasiskās MVC arhitektūras, izmantojot mūsu priekšējās lietotnes.

Kad arvien vairāk izstrādātāju sāk redzēt komponentu un vienvirziena arhitektūru priekšrocības, galvenā uzmanība tiks pievērsta labāku rīku un bibliotēku veidošanai, kas iet pa šo ceļu.

Vai šāda veida arhitektūra būs labākais risinājums pēc pieciem gadiem? Ir lielas izredzes, ka tas notiks, taču atkal nekas nav skaidrs.

Pirms pieciem gadiem neviens nevarēja paredzēt, kā mēs šodien nonāksim pie lietotņu rakstīšanas. Tāpēc es nedomāju, ka likmju izdarīšana nākotnē ir droša.

Tas arī viss! Es ceru, ka jums patika šo lasīt. Es atzinīgi vērtēju jūsu atsauksmes zemāk.

Ja jums patika raksts, noklikšķiniet uz zaļās sirds zemāk, un es zināšu, ka mani centieni nav veltīgi.