Model-Viewer-Controller

Стандартна схема архітектури «Модель-Вид-Контролер» зображена на наступному малюнку:

Схема архитектуры MVC

Розберемо по пунктах дану схему.

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

Модель є «суттю» системи і відповідає за безпосередні алгоритми, розрахунки тощо внутрішній устрій системи.

Контролер є сполучною ланкою між «поданням» і «моделлю» системи, за допомогою якого і існує можливість зробити поділ між ними. Контролер отримує дані від користувача і передає їх в «модель». Крім того, він отримує повідомлення від моделі, і передає їх в «подання».

Стосовно до інтернет-додатків існує думка, що частини контролера і подання об'єднані, тому що за відображення і одночасно за введення інформації відповідає браузер. З цим можна погодитися, а можна не погоджуватися і виділити контролер в окрему частину, що ми і зробимо.

Отже, домовимося:

Представлення. Модуль виведення інформації. Це може бути шаблонізатор або що-небудь подібне, мета якого є тільки в поданні інформації у вигляді HTML на основі будь-яких готових даних.

Контролер. Модуль управління введенням і виведенням даних. Даний модуль повинен стежити за переданими в систему даними (через форму, рядок запиту, cookie або будь-яким іншим способом) і на основі введених даних вирішити:

• Передавати чи їх у модель

• Вивести повідомлення про помилку і запросити повторне введення (змусити модуль уявлення оновити сторінку з урахуванням умов)

Крім того, контролер зобов'язаний визначати тип даних, отриманих від моделі (чи є це готовий результат, відсутність повідомлення про помилку) і передавати інформацію в модуль уявлення.

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

Досить складно з першого разу розібратися і зрозуміти. На це потрібен час і відповідний проект.

Але насправді нічого надскладного в цьому немає.

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

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

На цій діаграмі показана послідовність дій, а також послідовність переданих даних: від користувача, до користувача і між модулями. Схема відображає типовий процес виведення форми, заповнення її користувачем і повернення користувачеві результатів. Ніяких помилок в даному випадку не відбувається.

Діаграма послідовностей

Як видно з діаграми, звернення до моделі відбувається лише в разі надсилання користувачем вірних даних. На внутрішньому ж рівні додатку, модель відокремлена від подання та контролера. Контролер також відділений від моделі і уявлення, і його функція полягає в управлінні та перевірці.