Составные паттерны и MVC
Модель и масштаб — Основы БД, опорные темы, проектирование БД, пакетная работа. Карта — о разделе.
В продакшене паттерны редко живут по одному. Типичный UI-сценарий (пульт управления, симулятор, дашборд) одновременно использует Адаптер, Декоратор, Наблюдатель и Компоновщик. Частый архитектурный каркас таких систем — Model–View–Controller (MVC). Здесь — как разложить роли и не перепутать MVC с "тремя папками в репозитории".
Play ITЗагрузка интерактивного демо…
MVC — три роли
| Роль | Ответственность | Что не должна делать |
|---|---|---|
| Model | Данные и бизнес-правила (BPM, плейлист, заказ) | Рисовать UI и знать про кнопки |
| View | Отображение состояния модели | Менять правила расчёта скидки |
| Controller | Реакция на ввод пользователя, вызов операций модели | Хранить долгоживущее состояние домена |
Поток запроса: пользователь действует во View → Controller обновляет Model → Model уведомляет подписанные View → View перерисовывается.
В классическом примере с моделью ритма (BPM) модель хранит темп и список слушателей; представление (слайдеры, диаграмма) подписывается на изменения и не опрашивает модель в цикле — это прямое применение Наблюдателя / Наблюдателя в C#.
Какие паттерны GoF "сидят" внутри MVC
| Паттерн | Роль в MVC | Пример |
|---|---|---|
| Observer | Model → View: слабая связь, автоматическое обновление UI | PropertyChangeListener, React state, SignalR push |
| Strategy | Подключаемые алгоритмы внутри модели или контроллера | Разные способы сортировки плейлиста, расчёта доставки |
| Command | Действие пользователя как объект (undo, очередь, макрос) | Кнопка "Play" упаковывает вызов в команду с историей |
| Composite | Дерево виджетов или меню | Панель содержит слайдеры и кнопки как единый Component |
| Decorator | Дополнительное оформление View без подклассов | Обводка, тени, логирование отрисовки |
MVC — архитектурный каркас; перечисленные шаблоны — тактические кирпичи внутри него. Обзор архитектурных стилей шире — в Архитектурных паттернах.
Составной сценарий — несколько паттернов сразу
Условный симулятор уток в одном модуле может сочетать:
- утки с разным "кряканьем" — Стратегия;
- подсчёт кряков — Декоратор вокруг
Quackable; - индюк за "уткой" — Адаптер;
- MVC для DJ-пульта — Model + View + Controller.
Урок для практики: один паттерн решает одну ось изменений. Если задача — только совместить API индюка и утки, достаточно Адаптера; если ещё нужен счётчик событий — добавляется Декоратор.
MVC в корпоративном веб-приложении
Классический Spring Boot / ASP.NET MVC — это MVC плюс слои:
| Слой в проекте | Близкая роль MVC | Паттерны рядом |
|---|---|---|
| Controller / API | Controller | Фасад над сервисами |
| Service | Model (правила) | Стратегия, Команда |
| Repository | Model (доступ к данным) | Фабрика, DI |
| DTO + View (JSON, Razor, SPA) | View | Адаптер к внешнему API |
Практика в лаборатории — Spring Boot приложение — контроллер, сервис, репозиторий как разделение ответственности, а не как формальное "MVC ради MVC".
В распределённой системе "моделью" часто становится сервис домена, "представлением" — SPA или BFF, "контроллером" — API-шлюз или REST-слой. Идея та же: изменение бизнес-правил не должно тянуть переписывание всех экранов.
Чек-лист перед внедрением MVC
- Есть ли несколько представлений одних и тех же данных (веб, мобильное, отчёт)?
- Нужно ли обновлять UI при изменении модели без опроса?
- Отделены ли тесты бизнес-логики от UI-фреймворка?
Если ответ "нет" на все три вопроса, достаточно тонкого API и одного клиента — полноценный MVC может быть избыточен.
См. также
- Принципы ОО-проектирования перед паттернами
- Частые паттерны GoF
- Посредник в Java — альтернатива "спагетти" связей между виджетами
- Жизненный цикл Spring MVC — как запрос проходит контроллер в Spring
- REST/BFF и путь HTTP-запроса — 2.04 Сайты, REST API