Model-view-controller (MVC. «Модель-вистава-поведінка», «Модель-вистава-контролер») - схема використання декількох шаблонів проектування. за допомогою яких модель даних програми, призначений для користувача інтерфейс і взаємодія з користувачем розділені на три окремих компонента так, що модифікація одного з компонентів надає мінімальний вплив на інші. Дана схема проектування часто використовується для побудови архітектурного каркаса, коли переходять від теорії до реалізації в конкретній предметній області [1].
Концепція MVC була описана в 1979 році [2] Трюгве Реенскаугом (англ. Trygve Reenskaug), тоді працюють над мовою програмування Smalltalk в Xerox PARC. Оригінальна реалізація описана в статті «Applications Programming in Smalltalk-80: How to use Model-View-Controller» [3]. Потім Джим Алтофф з командою розробників реалізували версію MVC для бібліотеки класів Smalltalk-80.
В оригінальній концепції була описана сама ідея і роль кожного з елементів моделі, уявлення і контролера. Але зв'язку між ними були описані без конкретизації. Крім того, розрізняли дві основні модифікації:
- Пасивна модель - модель не має ніяких способів впливати на уявлення або контролер, і використовується ними як джерело даних для відображення. Всі зміни моделі відслідковуються контролером і він же відповідає за перерисовку уявлення, якщо це необхідно. Така модель частіше використовується в структурному програмуванні. так як в цьому випадку модель являє просто структуру даних, без методів їх обробляють.
- Активна модель - модель оповіщає уявлення про те, що в ній відбулися зміни, а уявлення, які зацікавлені в оповіщенні, підписуються на ці повідомлення. Це дозволяє зберегти незалежність моделі як від контролера, так і від уявлення.
Класичною реалізацією концепції MVC прийнято вважати версію саме з активною моделлю.
призначення
Основна мета застосування цієї концепції полягає в поділі бізнес-логіки (моделі) від її візуалізації (уявлення. Виду). За рахунок такого поділу підвищується можливість повторного використання. Найбільш корисне застосування даної концепції в тих випадках, коли користувач повинен бачити ті ж самі дані одночасно в різних контекстах і / або з різних точок зору. Зокрема, виконуються наступні завдання:
- До однієї моделі можна приєднати кілька видів. при цьому не зачіпаючи реалізацію моделі. Наприклад, деякі дані можуть бути одночасно представлені у вигляді електронної таблиці, гістограми і кругової діаграми.
- Не торкаючись реалізацію видів. можна змінити реакції на дії користувача (натискання мишею на кнопці, введення даних), для цього досить використовувати інший контролер.
- Ряд розробників спеціалізується тільки в одній з областей: або розробляють графічний інтерфейс, або розробляють бізнес-логіку. Тому можливо добитися того, що програмісти, які займаються розробкою бізнес-логіки (моделі), взагалі не будуть обізнані про те, яке уявлення буде використовуватися.
Концепція MVC дозволяє розділити дані, подання та обробку дій користувача на три окремих компоненти:
- Модель (англ. Model). Модель надає знання: дані та методи роботи з цими даними, реагує на запити, змінюючи свій стан. Не містить інформації, як ці знання можна візуалізувати.
- Подання. вид (англ. View). Відповідає за відображення інформації (візуалізацію). Часто в якості уявлення виступає форма (вікно) з графічними елементами.
- Контролер (англ. Controller). Забезпечує зв'язок між користувачем і системою: контролює введення даних користувачем і використовує модель і уявлення для реалізації необхідної реакції.
Важливо відзначити, що як уявлення. так і контролер залежать від моделі. Однак модель не залежить ні від уявлення. ні від контролера. Тим самим досягається призначення такого поділу: воно дозволяє будувати модель незалежно від візуального представлення. а також створювати кілька різних уявлень для однієї моделі.
Для реалізації схеми Model-View-Controller використовується досить велика кількість шаблонів проектування (в залежності від складності архітектурного рішення), основні з яких «спостерігач», «стратегія», «компоновщик» [5].
Найбільш часті помилки
Початківці програмісти (особливо в веб-програмуванні. Де абревіатура MVC стала популярна) дуже часто трактують архітектурну модель MVC як пасивну модель MVC. У цьому випадку модель виступає виключно сукупністю функцій для доступу до даних, а контролер містить бізнес-логіку. В результаті код моделей за фактом є засобом отримання даних з СУБД. а контролер являє собою типовий модуль, наповнений бізнес-логікою, або скрипт в термінології веб-програмування. В результаті такого розуміння MVC розробники стали писати код, який Pádraic Brady, відомий в колах спільноти Zend Framework, охарактеризував як ТТУК - «Товсті тупі потворні контролери» (Fat Stupid Ugly Controllers) [6]:
Середньостатистичний ТТУК отримував дані з БД (використовуючи рівень абстракції бази даних, роблячи вигляд, що це модель) або маніпулював, валідованого, записував, а також передавав дані в вид. Такий підхід став дуже популярний тому, що використання таких контролерів схоже на класичну практику використання окремого php-файлу для кожної сторінки додатка.
Але в об'єктно-орієнтованому програмуванні використовується активна модель MVC, де модель - це не тільки сукупність коду доступу до даних і СУБД, а вся бізнес-логіка. У свою чергу, контролери являють собою лише елементи системи, в чиї безпосередні обов'язки входить прийом даних із запиту і передача їх іншим елементам системи. Тільки в цьому випадку контролер стає «тонким» і виконує виключно функцію сполучної ланки (glue layer) між окремими компонентами системи.
Приклад контролера MVC в рамках PHP5
На початку за допомогою методу контролера getView () програміст отримує об'єкт Уявлення (View), який викликає методи, специфічні для Уявлення (View): метод loadI18n () за допомогою якого в Представлення (View) завантажуються файли інтернаціоналізації. а також метод initTitle (). формує title HTML-сторінки на основі даних, отриманих в ході розбору файлів інтернаціоналізації.
Далі через метод контролера checkAccess () перевіряється, чи має користувач доступ до цієї сторінки. Якщо доступ не дозволений, формується попередження і відбувається перенаправлення на ресурс «/ admin /». Далі інстанціруется Модель (Model), а точніше, один з компонентів моделі - сервіс Krugozor_Module_Advert_Service_List. Даний клас інкапсулює логіку отримання масиву об'єктів моделей на основі різних параметрів з об'єкта запиту Request. а також взаємодіє з об'єктом пагінацію.
У прикладі явно видно, що Контролер є сполучною ланкою між двома основними компонентами системи - Моделлю (Model) і Виставою (View). Модель нічого «не знає» про Поданні, а Контролер не містить в собі будь-якої бізнес-логіки.
Примітки
література
- У Віківерситет є матеріали по темі Поділ візуалізації і бізнес-логіки
- Сергій Бердачук. Eclipse RCP. Файловий менеджер
- Model-View-Controller в .Net
- Узагальнений Model-View-Controller
- Тріада MVC в дії
- MVC для початківців
- Розробка вбудованих додатків з використанням eSWT