Частина 7. Ознайомлення з патерном MVC (Model-View-Controller)

Цей матеріал - частина циклу "Введення в Enterprise-розробку". Попередні статті:

• про мережу ;
• про архітектуру ПЗ ;
• про протоколи HTTP/HTTPS ;
• про основи Maven ;
• про сервлети (пишемо просте веб-додаток) ;
• про контейнери сервлетів .

У цьому матеріалі ми познайомимося з тобою з такою штукою, як MVC. Поговоримо про те, що таке MVC, торкнемося історії його створення, розберемося з основними ідеями та концепціями, закладеними в MVC, розглянемо покроково, як розбити додаток на модулі Модель, Вид, Контролер, а також напишемо невеликий веб-додаток на Spring-Boot, і на прикладі Spring-MVC подивимося, як дані передаються з Java коду в html сторінки. Щоб зрозуміти цей матеріал, тобі потрібно бути знайомим із шаблонами проектування, особливо з Спостерігачем (Observer) та Фасадом (Facade). Бути знайомим з HTTP запитами та відповідями, розуміти основи html, знати, що таке інструкції в Java. Сідайте зручніше, заварюйте чай, готуй десерт, салат, друге і перше. Ми починаємо.

Історія створення MVC

Ідеї ​​MVC сформулював Трюгве Реєнскауг (Trygve Reenskaug) під час роботи у Xerox PARC наприкінці 70-х років. У ті часи для роботи з ЕОМ не обійтися без наукового ступеня і постійного вивчення об'ємної документації. Завдання, яке Реенскауг вирішував разом із групою дуже сильних розробників, полягала у тому, щоб спростити взаємодію пересічного користувача з комп'ютером. Необхідно було створити кошти, які з одного боку були б гранично простими та зрозумілими, а з іншого — давали б можливість керувати комп'ютером та складними програмами. Реєнскауг працював у команді, яка займалася розробкою портативного комп'ютера "для дітей різного віку" - Dynabook, а також мови SmallTalk під керівництвом Алана Кея (Alan Kay). Саме тоді й там закладалися поняття доброзичливого інтерфейсу. Робота Реєнськауга разом із командою багато в чому вплинула на розвиток сфери IT. Наведемо цікавий факт, який безпосередньо не відноситься до MVC, але ілюструє значущість тих розробок. У 2007 році після презентації Apple iPhone Алан Кей сказав: “Коли вийшов Macintosh, у Newsweek запитали, що я про нього думаю. Я сказав: це перший персональний комп'ютер, гідний критики. Після презентації Стів Джобс підійшов і запитав: чи гідний iPhone критики? І я відповів: Зробіть його розміром п'ять на вісім дюймів, і ви завоюєте мир”. Через 3 роки, 27 січня 2010 року, Apple представила iPad діагоналлю 9,7 дюйми. Тобто Стів Джобс майже буквально дотримувався поради Алана Кея. Проект, над яким працював Реннскауг, вівся протягом 10 років. А перша публікація про MVC від його творців побачила світ ще через 10 років. Мартін Фаулер, автор низки книг та статей з архітектури ПЗ, згадує, що він вивчав MVC за працюючою версією SmallTalk. Оскільки інформації про MVC з першоджерела довго не було, а також з інших причин, з'явилася велика кількість різних трактувань цього поняття. В результаті багато хто вважає MVC схемою або патерном проектування. Рідше MVC називають складеним патерном або комбінацією кількох патернів, що працюють спільно для реалізації складних програм. Але насправді, як було сказано раніше, MVC - це насамперед набір архітектурних ідей/принципів/підходів, які можна реалізувати різними способами з використанням різних шаблонів... Далі ми спробуємо розглянути основні ідеї, закладені в концепції MVC.

Що таке MVC: основні ідеї та принципи

• VC - це набір архітектурних ідей і принципів для побудови складних інформаційних систем з інтерфейсом користувача;
• MVC – це абревіатура, яка розшифровується так: Model-View-Controller.

Дисклеймер: MVC – це не патерн проектування. MVC - це саме набір архітектурних ідей і принципів для побудови складних систем з інтерфейсом користувача. Але для зручності, щоб щоразу не повторювати: “Набір архітектурних ідей…”, ми називатимемо MVC патерном. Почнемо із простого. Що ж ховається за словами Model-View-Controller? При розробці систем з інтерфейсом користувача, слідуючи патерну MVC потрібно розділяти систему на три складові. Їх, своєю чергою, можна називати модулями чи компонентами. Говори як хочеш, але поділи на три. Кожна складова компоненти матиме своє призначення. Model. Перша компонента/модуль – так звана модель. Вона містить всю бізнес-логіку програми. View.Друга частина системи – вид. Цей модуль відповідає за відображення даних користувачеві. Усі, що бачить користувач, генерується видом. Controller.Третьою ланкою цього ланцюга є контролер. У ньому зберігається код, який відповідає за обробку дій користувача (будь-яка дія користувача в системі обробляється в контролері). Модель – найнезалежніша частина системи. Така незалежна, що вона не повинна нічого знати про модулі Вид і Контролер. Модель настільки незалежна, що її розробники можуть практично нічого не знати про Від і Контролер. Основне призначення Виду - надавати інформацію з Моделі у зручному для сприйняття користувача форматі. Основне обмеження Виду — він не повинен змінювати модель. Основне призначення Контролера – обробляти дії користувача. Саме через Контролер користувач вносить зміни до моделі. Точніше дані, які зберігаються в моделі. Наведемо ще раз схему, яку тобі вже показували на лекції: З цього можна зробити цілком логічний висновок. Складну систему слід розбивати на модулі. Опишемо коротко кроки, як можна досягти такого поділу.

Крок 1. Відокремити бізнес-логіку програми від інтерфейсу користувача

Ключова ідея MVC полягає в тому, що будь-яка програма з інтерфейсом користувача в першому наближенні можна розбити на 2 модулі: модуль, що відповідає за реалізацію бізнес-логіки програми, і інтерфейс користувача. У першому модулі буде реалізовано основний функціонал програми. Даний модуль буде ядром системи, в якому реалізується модель предметної області застосування. У концепції MVC цей модуль буде нашою буквою M, тобто. моделлю. У другому модулі буде реалізований весь інтерфейс користувача, включаючи відображення даних користувачеві і логіку взаємодії користувача з додатком. Основна мета такого поділу – зробити так, щоб ядро ​​системи (Модель у термінології MVC) могло незалежно розроблятися та тестуватися. Архітектура програми після такого поділу буде виглядати так:

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

Тут ми маємо 2 цілі:

1. Досягти ще більшої незалежності моделі.
2. Синхронізувати інтерфейси користувача.

Зрозуміти, що мається на увазі під синхронізацією інтерфейсів користувача, допоможе наступний приклад. Припустимо, ми купуємо квиток у кіно через інтернет і бачимо кількість вільних місць у кінотеатрі. Одночасно з нами купувати квиток у кіно може хтось ще. Якщо цей хтось купить квиток раніше за нас, нам би хотілося побачити, що кількість вільних місць на наш сеанс зменшилася. А тепер поміркуємо про те, як це може бути реалізовано всередині програми. Припустимо, у нас є ядро ​​системи (наша модель) та інтерфейс (веб сторінка, на якій ми здійснюємо покупку). На сайті 2 користувача одночасно вибирають місце. Перший користувач купив квиток. Другому користувачеві необхідно відобразити цю інформацію на сторінці. Як це має статися? Якщо ми з ядра системи оновлюватимемо інтерфейс, наше ядро, наша модель, буде залежною від інтерфейсу. При розробці та тестуванні моделі доведеться пам'ятати різні способи оновлення інтерфейсу. Для цього необхідно реалізувати шаблон Спостерігач. З його допомогою модель розсилає повідомлення про зміни всім передплатникам. Інтерфейс, будучи таким передплатником, отримає повідомлення та оновиться. Шаблон Спостерігач дозволяє моделі з одного боку інформувати інтерфейс (вид і контролер) про те, що в ній відбулися зміни, а з іншого - фактично нічого про них не знати, і тим самим залишатися незалежною. З іншого боку, це дозволить синхронізувати інтерфейси користувача. З його допомогою модель розсилає повідомлення про зміни всім передплатникам. Інтерфейс, будучи таким передплатником, отримає повідомлення та оновиться. Шаблон Спостерігач дозволяє моделі з одного боку інформувати інтерфейс (вид і контролер) про те, що в ній відбулися зміни, а з іншого - фактично нічого про них не знати, і тим самим залишатися незалежною. З іншого боку, це дозволить синхронізувати інтерфейси користувача. З його допомогою модель розсилає повідомлення про зміни всім передплатникам. Інтерфейс, будучи таким передплатником, отримає повідомлення та оновиться. Шаблон Спостерігач дозволяє моделі з одного боку інформувати інтерфейс (вид і контролер) про те, що в ній відбулися зміни, а з іншого - фактично нічого про них не знати, і тим самим залишатися незалежною. З іншого боку, це дозволить синхронізувати інтерфейси користувача.

Крок 3. Поділ інтерфейсу на Вид та Контролер

Продовжуємо ділити програму на модулі, але вже на нижчому рівні ієрархії. На цьому кроці інтерфейс користувача (який був виділений в окремий модуль на кроці 1) ділиться на вигляд і контролер. Важко провести сувору межу між видом і контролером. Якщо говорити про те, що вид це те, що бачить користувач, а контролер це механізм, завдяки якому користувач може взаємодіяти з системою, можна виявити деяке протиріччя. Елементи керування, наприклад, кнопки на веб-сторінці або віртуальна клавіатура на екрані телефону, це, по суті, частина контролера. Але вони так само видно користувачеві, як будь-яка частина виду. Тут швидше йдеться про функціональний поділ. Основне завдання інтерфейсу користувача - забезпечити взаємодію користувача з системою. Це означає, що в інтерфейсу всього 2 функції:

• виводити та зручно відображати користувачеві інформацію про систему;
• вводити дані та команди користувача в систему (передавати їх системі);

Дані функції визначають те, як потрібно ділити інтерфейс на модулі. У результаті, архітектура системи виглядає так: Отже, у нас з'явився додаток із трьох модулів, які називаються Модель, Вид та Контролер. Резюмуємо:

1. Дотримуючись принципів MVC, систему потрібно розділяти на модулі.
2. Найважливішим і найнезалежнішим модулем має бути модель.
3. Модель – ядро ​​системи. Потрібна можливість розробляти та тестувати її незалежно від інтерфейсу.
4. Для цього на першому етапі сегрегації системи необхідно розділити її на модель та інтерфейс.
5. Далі, за допомогою шаблону Спостерігач, зміцнюємо модель в її незалежності і отримуємо синхронізацію інтерфейсів користувача.
6. Третім кроком ділимо інтерфейс на контролер та вигляд.
7. Все, що на введення інформації від користувача в систему - це контролер.
8. Все що на виведення інформації від системи до користувача це у вид.

Залишилось обговорити ще одну важливу річ і можна пити якао.

Трохи про взаємозв'язок Віду та Контролера з Моделью

Коли користувач вводить інформацію через контролер, він тим самим вносить зміни до моделі. Принаймні користувач вносить зміни до даних моделей. Коли користувач отримує інформацію через елементи інтерфейсу (через Вигляд), користувач отримує інформацію про дані моделі. Як це відбувається? Через що Вид і Контролер взаємодіють із моделлю? Адже не може бути так, що класи Вида безпосередньо використовують методи класів Моделі для читання/запису даних, інакше ні про яку незалежність Моделі не може бути й мови. Модель представляє тісно пов'язаний між собою набір класів, до яких, по-хорошому, ні Вида, ні Контролера не повинно бути доступу. Для зв'язку моделі з видом і контролером необхідно реалізувати шаблон проектування Фасад. Фасад моделі буде тим самим прошарком між Моделью та інтерфейсом, через яку Вид отримує дані у зручному форматі, а Контролер змінює дані, викликаючи потрібні методи фасаду. Схематично, зрештою, все виглядатиме так:

MVC: у чому прибуток?

Основна мета дотримання принципів MVC - відокремити реалізацію бізнес-логіки програми (моделі) від її візуалізації (виду). Такий поділ підвищить можливість повторного використання коду. Користь застосування MVC найбільш наочна у випадках, коли користувачеві потрібно надавати ті самі дані в різних формах. Наприклад, як таблиці, графіка чи діаграми (використовуючи різні види). При цьому, не торкаючись реалізації видів, можна змінити реакції на дії користувача (натискання мишею на кнопці, введення даних). Якщо дотримуватися принципів MVC, можна спростити написання програм, підвищити читання коду, полегшити розширення та підтримку системи в майбутньому. У завершальному матеріалі циклу "Введення в Enterprise-розробку" ми з тобою подивимося на реалізацію MVC на прикладі Spring-MVC. Частина 8. Пишемо невелику програму на spring-boot