Помер MVC для фронтенда?


В цій статті хочу поділитися перекладом цікавих роздумів на тему минулого і сьогодення в архітектурі фронтенда.

У той час як все більше і більше фронтенд-розробників переймають підходи до односпрямованої архітектурою, виникає питання — чи є майбутнє у класичного MVC? Щоб зрозуміти, як ми дійшли до такого питання, давайте трохи проаналізуємо еволюцію архітектури фронтенда.

За останні 4 роки я бачив безліч веб-проектів і витратив чимало часу на розробку архітектури фронтенда та інтегрування різних фреймворків.

До 2010 року JavaScript (мова програмування, на якому був написаний jQuery) використовувався, в основному, для маніпуляцій з DOM і прикручування додаткової логіки, оживляючої веб-додатки. Розробників не надто хвилювала архітектура, оскільки штуки на зразок revealing module pattern цілком справлялися із завданням структурування кодової бази.

Дискусії на тему архітектури фронтенда в порівнянні з бекендом фактично почалися з розвитком концепції single page application (в кінці 2010 року) і з зростаючою популярністю фреймворків типу Backbone і Knockout.

Оскільки тоді це було нововведенням, розробники цих фреймворків змушені були шукати натхнення на стороні, так що вони звернулися до вже добре усталеним практикам, застосовуваним на серверній стороні. А до того моменту всі популярні серверні фреймворки в тому чи іншому вигляді реалізовували класичний MVC (Model — View — Controller), також відомий як MV* різних варіацій.

Коли React.js вперше був представлений як бібліотека візуалізації, багато почали його висміювати за інтуїтивно незрозумілі маніпуляції з HTML в JavaScript. Але розробники випустили з виду найважливіший внесок, який приніс світові React, — компонентно-орієнтовану архітектуру. React не винайшов компонентний підхід, але переніс ідею на новий рівень.

Цей головний прорив в архітектурі прогледіли навіть в Facebook, коли вони анонсували React як «V MVC».

Примітка: мене досі переслідують кошмари після рев'ю проектів, в яких одночасно використовувалися React і Angular 1.x.

2015 рік став поворотним для свідомості розробників — від звичного MVC ми перейшли до однонаправленим архітектур і потоків даних, успадкованим від Flux і функціонального реактивного програмування, за допомогою таких інструментів, як Redux або RxJS.

Коли ж для MVC все пішло не так?
MVC досі залишається, мабуть, найкращим способом розробки серверної частини додатків. Працювати з фреймворками зразок Rails або Django — одне задоволення.

Корінь проблеми в тому, що принципи та декомпозиції, які MVC є на сервері, не такі ж, як на клієнті.

Зв'язок контролер-подання
Діаграма нижче показує, як контролер і подання взаємодіють на сервері. Між ними всього дві точки взаємодії, обидві вони перетинають кордон між сервером і клієнтом.

Коли ми переносимо MVC на клієнт, починаються проблеми. Контролери нагадують те, що ми називаємо «code-behind». Контролер сильно залежить від уявлення. У більшості реалізацій фреймворків він навіть створюється поданням (як у випадку, наприклад, ng-controller в Angular).

Крім цього, якщо згадати принцип єдиної відповідальності, це пряме порушення правил. Код клієнтського контролера в певній мірі має справу і з обробкою подій з бізнес-логікою.

Товсті моделі
Згадайте, які типи даних ви зберігаєте у моделі на клієнтській стороні.

З одного боку, у вас є дані типу users products, що представляють стан програми. З іншого боку вам доводиться зберігати стан інтерфейсу — що-небудь на зразок showTab або selectedValue.

Так само як і контролер, модель порушує принцип єдиної відповідальності, оскільки у вас немає окремих способів управління станом додатки і станом інтерфейсу.

Так де в цій моделі місце компонентам?
Компоненти представляють із себе: подання + обробка подій + стан інтерфейсу.

Діаграма нижче показує як фактично розділити стандартну модель MVC, щоб отримати компоненти. Вище лінії залишилося саме те, що намагається вирішити Flux: управління станом додатки та бізнес-логікою.

Одночасно з популярністю React і компонентно-орієнтованої архітектури ми також побачили зростаючу популярність односпрямованої архітектури для управління станом додатки.

Однією з причин їхнього успішного спільного застосування стало те, що вони удвох повністю покривають класичний MVC підхід. Вони до того ж забезпечують набагато більш гарне поділ відповідальності при побудові фронтенд-архітектури.

Але це більше не розповідь про один React. Angular 2 можна побачити, точно такі ж підходи, хоча і з різними варіантами управління станом (наприклад, ngrx/store).

MVC не міг зробити нічого краще на клієнті. Він з самого початку був приречений на провал. Нам лише потрібно було час, щоб це побачити. Через цей п'ятирічний процес фронтенд-архітектура еволюціонувала в те, що ми бачимо сьогодні. І якщо подумати, то п'ять років не так вже й багато для того, щоб виробити кращі практики.

MVC був необхідний в самому початку, тому що наші фронтенд-додатки ставали все більше і складніше, а ми не знали як їх структурувати. Я думаю, він впорався зі своїм призначенням і заодно дав хороший урок про те, як брати гарну практику з одного контексту (сервера) і застосовувати її в іншому (клієнта).

Що ж нам готує майбутнє?
Я не думаю, що найближчим часом ми повернемося до класичної архітектури MVC для клієнтських додатків.

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

Чи буде такий тип архітектури кращим рішенням через п'ять років? Цілком можливо, що так. Але знову ж, немає нічого певного.

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

Від перекладача
Я фул-стек розробник у відділі фронтенда Tutu.ru, досвід роботи 5 років. Раніше писала на C#, зараз пишу JavaScript/Node.js і PHP.

В Tutu.ru фронтенд пройшов чималий шлях — від підсвічування маршруту електрички при наведенні (хто не знає, Електрички — наш самий старий проект) до повноцінного SPA (single page application) у новому розділі Автобуси.

До 2013 року у нас не було відділу фронтенд-розробки, хоча JavaScript, звичайно ж, використовувався. Всі розробники були фул-стек майстрами, але «вихідцями» з бекенду. Тому цілком логічно, що коли клієнтська кодова база ускладнилася настільки, що треба було її якось структурувати, розробники спробували перенести звичний і рідний MVC з бекенду на фронтенд.

Це було краще, ніж нічого, але згодом ми зіткнулися з проблемами, добре описаними в статті. У 2014 році ми поступово почали переходити на односпрямовані архітектури і тепер MVC у нас живе тільки на бэкенде (і в легасі-фронтенде, на правах почесного ветерана).
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.