Мъртъв ли е Model-View-Controller на предния край?

Все повече и повече предни разработчици възприемат еднопосочни архитектури. И така, какво е бъдещето на класическия подход на Model-View-Controller (MVC)?

За да разберем как стигнахме до този момент, нека първо разгледаме еволюцията на архитектурата отпред.

През последните четири години работих по много уеб проекти и прекарах доста време в архитиране на предни краища и интегриране на рамка в тях.

Преди 2010 г. JavaScript - в който е написан езикът за програмиране jQuery - се използва най-вече за добавяне на DOM манипулация към традиционните уебсайтове. Изглежда разработчиците не се интересуваха много от самата архитектура. Неща като модела на разкриващия модул бяха достатъчно добри, за да структурират нашите кодови бази.

Текущата ни дискусия за архитектурата отпред и отзад се появи едва в края на 2010 г. Тогава разработчиците започнаха да приемат сериозно концепцията за приложение на една страница . Това е и когато рамки като Backbone и Knockout започват да стават популярни.

Тъй като много от принципите, около които бяха изградени тези рамки, бяха доста нови по това време, техните дизайнери трябваше да търсят другаде за вдъхновение. Те заимстваха практики, които вече бяха добре установени за сървърната архитектура. И в този момент всички популярни рамки от страна на сървъра включват някакъв вид изпълнение на класическия модел MVC (известен също като MV * поради неговите вариации).

Когато React.js беше представен за първи път като библиотека за рендиране, много разработчици се подиграха с него, защото възприеха начина му на работа с HTML в JavaScript като контраинтуитивен. Но те пренебрегнаха най-важния принос, който React внесе на масата - Компонентна архитектура .

React не е измислил компоненти, но е направил тази идея още една стъпка напред.

Този основен пробив в архитектурата е пропуснат дори от Facebook, когато рекламират React като „V в MVC“.

Като странична бележка, все още сънувам кошмари, след като прегледах кодова база, която работеше заедно както Angular 1.x, така и React.

2015 ни донесе голяма промяна в мисленето - от познатия модел на MVC към еднопосочните архитектури и потоци от данни, получени от Flux и функционално реактивно програмиране, подкрепени от инструменти като Redux или RxJS

И така, къде всичко се обърка за MVC?

MVC все още е може би най-добрият начин за справяне със сървърната страна. Рамки като Rails и Django са удоволствие да работите.

Проблемите произтичат от факта, че принципите и разделенията, които MVC въведе на сървъра, не са същите като на клиента.

Свързване на контролер и изглед

По-долу има диаграма за това как изгледът и контролерът взаимодействат на сървъра. Между тях има само две точки на допир, и двете преминаващи границата между клиента и сървъра.

Когато преминете към MVC на клиента, има проблем. Контролерите наподобяват това, което наричаме „изоставане на кода“. Контролерът е силно зависим от изгледа. В повечето реализации на рамката той дори е създаден от View (както е в случая например с ng-контролера в Angular).

Освен това, когато мислите за принципа на единната отговорност, това очевидно нарушава правилата. Кодът на клиентския контролер се справя както с обработката на събития, така и с бизнес логиката на определено ниво.

Мазнини модели

Помислете малко за вида данни, които съхранявате в Модел от страна на клиента.

От една страна имате данни като потребители и продукти , които представляват състоянието на вашето приложение . От друга страна, трябва да съхраните UI State - неща като showTab или selectedValue .

Подобно на контролера, моделът нарушава принципа на единна отговорност, защото нямате отделен начин за управление на състоянието на потребителския интерфейс и състоянието на приложението .

И така, къде се вписват компонентите в този модел?

Компонентите са: Изгледи + обработка на събития + Състояние на потребителския интерфейс .

Диаграмата по-долу показва как всъщност разделяте оригиналния MVC модел, за да получите компонентите. Това, което остава над линията, е точно това, което Flux се опитва да реши: управление на състоянието на приложението и бизнес логиката .

С популярността на React и базирана на компоненти архитектура , видяхме възхода на еднопосочните архитектури за управление на състоянието на приложението.

Една от причините тези двамата да се съчетават толкова добре заедно е, че покриват изцяло класическия MVC подход. Те също така осигуряват много по-добро разделяне на проблемите, когато става въпрос за изграждане на предни архитектури.

Но това вече не е история на React. Ако погледнете Angular 2, ще видите, че се прилага точно същият модел, въпреки че имате различни опции за управление на състоянието на приложението като ngrx / store.

Всъщност нямаше нищо, което MVC да е направил по-добре за клиента. Беше обречен да се провали от самото начало. Просто ни трябваше време, за да видим това. Чрез този петгодишен процес архитектурата отпред се превърна в това, което е днес. И като се замислите, пет години не са толкова много, за да се появят най-добрите практики.

MVC беше необходим в началото, защото приложенията ни отпред бяха все по-големи и по-сложни и ние не знаехме как да ги структурираме. Мисля, че е изпълнил целта си, като същевременно е предоставил добър урок за вземане на добра практика от един контекст (сървъра) и прилагането й към друг (клиента).

И така, какво крие бъдещето?

Не мисля, че скоро ще се върнем към класическата архитектура на MVC за нашите приложения отпред.

Тъй като все повече разработчици започват да виждат предимствата на компонентите и еднопосочните архитектури, фокусът ще бъде върху изграждането на по-добри инструменти и библиотеки, които вървят по този път.

Ще бъде ли този вид архитектура най-доброто решение след пет години? Има голям шанс това да се случи, но отново нищо не е сигурно.

Преди пет години никой не можеше да предвиди как ще свършим да пишем приложения днес. Така че не мисля, че е безопасно да правите залози за в бъдеще сега.

Това е всичко! Надявам се да ви е харесало да четете това. Приветствам отзивите ви по-долу.

Ако статията ви е харесала, кликнете върху зеленото сърце по-долу и ще знам, че усилията ми не са напразни.