Je li Model-View-Controller mrtav na prednjem kraju?

Sve više i više front-end programera usvaja jednosmjerne arhitekture. Dakle, kakva je budućnost klasičnog pristupa Model-View-Controller (MVC)?

Da bismo razumjeli kako smo došli do ove točke, hajde da prvo razmotrimo evoluciju front-end arhitekture.

U posljednje četiri godine radio sam na velikom broju web projekata i proveo sam dosta vremena arhitektirajući front endove i integrirajući framework u njih.

Prije 2010. JavaScript - u kojem je napisan programski jezik jQuery - koristio se uglavnom za dodavanje DOM manipulacija tradicionalnim web mjestima. Čini se da programeri nisu mnogo marili za samu arhitekturu. Stvari poput otkrivajućeg uzorka modula bile su dovoljno dobre da strukturiraju naše baze kodova.

Naša trenutna rasprava o front-end i back-end arhitekturi nastala je tek krajem 2010. Tada su programeri počeli ozbiljno shvaćati koncept aplikacije na jednoj stranici . Tada su i okviri poput Backbone i Knockout počeli postajati popularni.

Budući da su mnogi principi oko kojih su ti okviri izgrađeni u to vrijeme bili sasvim novi, njihovi dizajneri morali su potražiti nadahnuće drugdje. Posudili su prakse koje su već bile dobro uspostavljene za arhitekturu na strani poslužitelja. I u tom su trenutku svi popularni okviri na strani poslužitelja uključivali neku vrstu implementacije klasičnog MVC modela (poznat i kao MV * zbog njegovih varijacija).

Kada je React.js prvi put predstavljen kao biblioteka za prikazivanje, mnogi programeri su mu se rugali jer su njegov način rada s HTML-om u JavaScript-u doživljavali protu-intuitivnim. Ali previdjeli su najvažniji doprinos koji je React donio na stol - Arhitektura zasnovana na komponentama .

React nije izmislio komponente, ali ide ovu ideju korak dalje.

Ovaj veliki proboj u arhitekturi previdio je čak i Facebook, kada su React reklamirali kao "V u MVC-u".

Uz napomenu, još uvijek imam noćne more nakon pregleda baze podataka koja je zajedno radila i Angular 1.x i React.

2015. donijela nam je veliku promjenu u razmišljanju - od poznatog MVC obrasca do jednosmjernih arhitektura i tokova podataka izvedenih iz protoka i funkcionalnog reaktivnog programiranja, podržanih alatima poput Redux ili RxJS.

Pa gdje je sve pošlo po zlu za MVC?

MVC je i dalje vjerojatno najbolji način za rješavanje problema na poslužitelju. Zadovoljstvo je raditi s okvirima poput Rails i Django.

Problemi proizlaze iz činjenice da principi i razdvajanja koja je MVC uveo na poslužitelju nisu isti kao na klijentu.

Spojnica kontroler-pogled

Ispod je dijagram kako View i Controller međusobno djeluju na poslužitelju. Između njih postoje samo dvije dodirne točke, obje prelazeći granicu između klijenta i poslužitelja.

Kada na klijentu pređete na MVC, postoji problem. Kontroleri nalikuju onome što nazivamo "kodnim zaostatkom". Upravljač jako ovisi o prikazu. U većini implementacija okvira, čak ga je stvorio i View (kao što je to slučaj, na primjer, s ng-kontrolerom u Angulu).

Uz to, kad pomislite na Načelo jedinstvene odgovornosti, ovo očito krši pravila. Kôd klijentskog kontrolera na određenoj se razini bavi i rukovanjem događajima i poslovnom logikom .

Masni modeli

Razmislite malo o vrsti podataka koje u modelu pohranjujete na klijentskoj strani.

S jedne strane imate podatke poput korisnika i proizvoda koji predstavljaju vaše stanje prijave . S druge strane, morate pohraniti UI State - stvari poput showTab ili selectedValue .

Slično kao i kontroler, Model krši načelo jedinstvene odgovornosti, jer nemate zaseban način upravljanja stanjem korisničkog sučelja i stanjem aplikacije .

Pa gdje se komponente uklapaju u ovaj model?

Komponente su: Prikazi + Rukovanje događajima + Stanje korisničkog sučelja .

Dijagram u nastavku prikazuje kako ste zapravo podijelili izvorni MVC model da biste dobili komponente. Ono što je ostalo iznad crte je upravo ono što Flux pokušava riješiti: upravljanje stanjem aplikacije i poslovnom logikom .

S popularnošću arhitekture React i komponenata , vidjeli smo porast jednosmjernih arhitektura za upravljanje stanjem aplikacije.

Jedan od razloga što se ovo dvoje tako dobro slažu je taj što u potpunosti pokrivaju klasični MVC pristup. Oni također pružaju puno bolje razdvajanje briga kada je u pitanju izgradnja front-end arhitektura.

Ali ovo više nije React priča. Ako pogledate Angular 2, vidjet ćete da se primjenjuje potpuno isti obrazac, iako imate različite mogućnosti za upravljanje stanjem aplikacije, poput ngrx / store.

Zapravo nije bilo ničega što je MVC mogao učiniti bolje na klijentu. Bilo je osuđeno na propast od početka. Samo nam je trebalo vremena da to vidimo. Kroz ovaj petogodišnji proces, front-end arhitektura evoluirala je u ono što je danas. A kad malo bolje razmislite, pet godina nije toliko dugo da se pojave najbolje prakse.

MVC je bio neophodan u početku jer su naše front end aplikacije postajale sve veće i složenije, a nismo znali kako ih strukturirati. Mislim da je poslužio svojoj svrsi, istovremeno pružajući dobru lekciju o uzimanju dobre prakse iz jednog konteksta (poslužitelja) i primjeni na drugi (klijent).

Pa, što nosi budućnost?

Ne mislim da ćemo se uskoro vratiti klasičnoj MVC arhitekturi za naše front end aplikacije.

Kako sve više i više programera počinju uviđati prednosti komponenata i jednosmjernih arhitektura, fokus će biti na izgradnji boljih alata i knjižnica koje idu tim putem.

Hoće li ovakva arhitektura biti najbolje rješenje za pet godina od sada? Postoje dobre šanse da se to dogodi, ali opet, ništa nije sigurno.

Prije pet godina nitko nije mogao predvidjeti kako ćemo danas završiti s pisanjem aplikacija. Tako da mislim da sada nije sigurno postavljati oklade za budućnost.

To je otprilike to! Nadam se da ste uživali čitajući ovo. Pozdravljam vaše povratne informacije u nastavku.

Ako vam se svidio članak, kliknite na zeleno srce ispod i znat ću da moj trud nije uzaludan.