Model-Viewer-Controller
Стандартна схема архітектури «Модель-Вид-Контролер» зображена на наступному малюнку:
Розберемо по пунктах дану схему.
У шаблоні MVC, як випливає з назви, є три основних компоненти: Модель, Представлення, і Контролер. Представлення відповідає за відображення інформації, що надходить із системи або в систему.
Модель є «суттю» системи і відповідає за безпосередні алгоритми, розрахунки тощо внутрішній устрій системи.
Представлення. Модуль виведення інформації. Це може бути шаблонізатор або що-небудь подібне, мета якого є тільки в поданні інформації у вигляді HTML на основі будь-яких готових даних.
Контролер. Модуль управління введенням і виведенням даних. Даний модуль повинен стежити за переданими в систему даними (через форму, рядок запиту, cookie або будь-яким іншим способом) і на основі введених даних вирішити:
- Передавати чи їх у модель
- Вивести повідомлення про помилку і запросити повторне введення (змусити модуль уявлення оновити сторінку з урахуванням умов)
Крім того, контролер зобов'язаний визначати тип даних, отриманих від моделі (чи є це готовий результат, відсутність повідомлення про помилку) і передавати інформацію в модуль уявлення.
Модель. Модуль, що відповідає за безпосередній розрахунок чого-небудь на основі отриманих від користувача даних. Результат, отриманий цим модулем, повинен бути переданий в контролер, і не повинен містити нічого, що відноситься до безпосереднього висновку (тобто має бути представлений у внутрішньому форматі програми).
Досить складно з першого разу розібратися і зрозуміти. На це потрібен час і відповідний проект.
Але насправді нічого надскладного в цьому немає.
Уявімо собі як представлення будь-якого класу, який за допомогою шаблонізатора виводить результат чи повідомлення про помилку. На його вхід подається або масив з даними (об'єкт або що-небудь інше), або змінна, що містить текст з помилкою. В якості контролера буде виступати клас, що виробляє всі необхідні перевірки коректності даних і генерує повідомлення про помилки. Перевірку даних доцільно помістити саме в клас контролера, їх використовують досить часто. Як варіант, можна просто успадковувати клас контролера від більш загального класу, що реалізує перевірку вхідних даних за заданими правилами. Або, якщо так буде зручніше, включити в клас контролера клас або серію функцій перевірки даних.
Цей же клас повинен передати дані, отримані в результаті роботи моделі, в клас представлення для виводу. Одними словами схему потоків даних у цій архітектурі пояснити складно, тому звернемося до мови UML і до діаграми послідовностей зокрема (незначні відступи від UML, прийняті в діаграмах, полягають в тому, що в деяких випадках разом з іменами сутностей або об'єктів, дані переказують в дужках).
На цій діаграмі показана послідовність дій, а також послідовність переданих даних: від користувача, до користувача і між модулями. Схема відображає типовий процес виведення форми, заповнення її користувачем і повернення користувачеві результатів. Ніяких помилок в даному випадку не відбувається.
Як видно з діаграми, звернення до моделі відбувається лише в разі надсилання користувачем вірних даних. На внутрішньому ж рівні додатку, модель відокремлена від подання та контролера. Контролер також відділений від моделі і уявлення, і його функція полягає в управлінні та перевірці.
