Модель-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).

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

Жирові моделі

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

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

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

Отже, де компоненти вписуються в цю модель?

Компонентами є: подання + обробка подій + стан інтерфейсу .

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

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

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

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

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

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

То що в майбутньому?

Я не думаю, що ми скоро повернемося до класичної архітектури MVC для наших інтерфейсних додатків.

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

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

П’ять років тому ніхто не міг передбачити, як ми закінчимо писати програми сьогодні. Тому я не думаю, що зараз можна робити ставки на майбутнє безпечно.

Ось і все! Сподіваюся, вам сподобалось це читати. Я вітаю ваші відгуки нижче.

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