Model-view-controller (MVC. «Модель-уявлення-поведінка», «модель-уявлення-контролер», «модель-вид-контролер») - схема використання декількох шаблонів проектування, за допомогою яких модель даних програми, призначений для користувача інтерфейс і взаємодія з користувачем розділені на три окремих компонента таким чином, щоб модифікація одного з компонентів надавала мінімальний вплив на інші. Дана схема проектування часто використовується для побудови архітектурного каркаса.
Незважаючи на те, що під абревіатурою MVC зазвичай розуміють ціле сімейство патернів, можна виділити початковий варіант даного архітектурного рішення. На даний момент, застосування MVC в оригінальному вигляді навряд чи буде виправдано, з різних причин, однак еволюцію паттерна краще простежити з самого початку ...
Вперше патерн MVC з'явився в мові SmallTalk в кінці сімдесятих. Власне завдання було добре всім знайома, треба було придумати архітектурне рішення, яке дозволяло б маніпулювати графічними уявленнями даних якогось додатка, таким чином, щоб зміна Уявлення цих даних не впливало на бізнес-логіку і дані (Модель) додатки, а так само, щоб була можливість мати кілька уявлень для однієї Моделі. Таким рішенням і став патерн MVC, ідея якого народилася в надрах Xerox PARK, і отримала своє перша публічна згадка в документації до SmallTalk'80. У класичному варіанті, MVC складається з трьох частин, які і дали йому назву.
Модель (Model)
Під Моделлю, зазвичай розуміється частина містить в собі функціональну бізнес-логіку програми. Модель повинна бути повністю незалежна від інших частин продукту. Модельний шар нічого не повинен знати про елементи дизайну, і яким чином він буде відображатися. Досягається результат, що дозволяє змінювати подання даних, то як вони відображаються, не чіпаючи саму Модель.
Модель володіє наступними ознаками:
- Модель - це бізнес-логіка програми;
- Модель володіє знаннями про себе саму і не знає про контролерах і уявленнях;
- Для деяких проектів модель - це просто шар даних (DAO, база даних, XML-файл);
- Для інших проектів модель - це менеджер бази даних, набір об'єктів або просто логіка додатка;
Подання (View)
В обов'язки Уявлення входить відображення даних отриманих від Моделі. Однак, уявлення не може безпосередньо впливати на модель. Можна говорити, що уявлення отримує доступ «тільки на читання» до даних.
Подання володіє наступними ознаками:
- У поданні реалізується відображення даних, які виходять від моделі будь-яким способом;
- У деяких випадках, уявлення може мати код, який реалізує деяку бізнес-логіку.
Приклади подання: HTML-сторінка, WPF форма, Windows Form.
До завдань Контролера входить реакція на зовнішні подразники і зміна Моделі і / або Подання відповідно до закладеної в нього логікою. Один Контролер може працювати з декількома Уявленнями. в залежності від ситуації, взаємодіючи з ними через якийсь заздалегідь відомий інтерфейс, який ці Уявлення реалізують. Важливий нюанс, в класичній версії MVC Контролер не займається передачею даних з Моделі в Представлення і не є медіатором (Mediator) між Моделлю і Уявленнями.
Міць шаблону MVC безпосередньо обумовлюється розподілом цих трьох елементів з метою уникнути перетинів зон відповідальності кожного з них і хоча кожен елемент в тріаді MVC має окрему і унікальну зону відповідальності, вони не функціонують в ізоляції. Насправді, з тим щоб скласти шаблон MVC, кожному елементу слід комунікувати з іншими.
Взаємодія елементів MVC
Кожен елемент в шаблоні MVC спілкується з іншими вельми специфічними способами. Коммуніцірованія реалізується послідовністю подій, які зазвичай запускаються взаємодією користувача з додатком. Послідовність подій виглядає так:
- Користувач взаємодіє з елементом інтерфейсу (наприклад, натискає на кнопку в Поданні).
- Подання відсилає подія натискання Контролеру, щоб вирішити, як це натискання обробити.
- Контролер змінює Модель на основі того, що він вирішив щодо натискання кнопки.
- Модель інформує Уявлення про те, що стан Моделі змінилося.
- Подання читає інформацію про стан в Моделі і самостійно видозмінюється.
Основна мета застосування цієї концепції полягає в поділі бізнес-логіки (моделі) від її візуалізації (уявлення. Виду). За рахунок такого поділу підвищується можливість повторного використання вже готових компонентів. Застосування такої схеми проектування як MVC дозволяє створювати складні системи, які можуть бути легко масштабованими без зміни їх структури.