Неточность в описании MVC: фактическая архитектура компонентов ближе к View-Model, документация вводит в заблуждение относительно роли class.php #73
Description
Описание проблемы
Текущая документация по архитектуре компонентов описывает структуру как реализацию паттерна MVC (Model-View-Controller), однако на практике разработчики сталкиваются с принципиальным несоответствием между теорией и реализацией. Это создает путаницу в понимании ролей файлов, особенно class.php, и приводит к нарушению SOLID-принципов в прикладном коде.
Конкретные несоответствия
1. Роль class.php как "Controller"
В документации class.php позиционируется как контроллер компонента, однако фактически он выполняет функции ViewModel (или Presenter):
- Отсутствует обработка HTTP-запроса: Класс не получает Request/Response объекты, не маршрутизирует действия (в отличие от
\Bitrix\Main\Engine\Controller). - Смешение ответственностей: В
class.phpпроисходит одновременно и получение данных (работа с Model), и их подготовка для отображения (логика ViewModel), и управление состоянием компонента. - Тесная связь с View: Через
$arResultпроисходит прямая передача данных в шаблон, что нарушает принцип "глупого" View из классического MVC.
2. Отсутствие выделенного слоя Model
В классическом MVC Model содержит бизнес-логику и правила работы с данными. В текущей архитектуре компонентов:
- Model размыта: Данные получаются напрямую через API модулей (
CIBlockElement::GetList, ORM), но бизнес-логика часто оседает прямо вclass.php. - Нет четкого контракта: Не описано, где должна находиться доменная логика — в
class.php, в отдельных классах-репозиториях, или в API ядра.
3. Конфликт терминологии с D7-контроллерами
С введением \Bitrix\Main\Engine\Controller появились настоящие MVC-контроллеры (с методами *Action, обработкой роутинга, JSON-ответами). Однако документация по компонентам продолжает использовать термин "контроллер" для class.php, что создает терминологическую коллизию:
- Разработчик не понимает, когда нужен "контроллер компонента", а когда — "Controller D7".
- Не объяснено, как эти два типа "контроллеров" соотносятся друг с другом.
Предлагаемые изменения
Вариант А: Уточнение терминологии (рекомендуется)
Изменить описание архитектуры с MVC на View-Model (или Presentation Model):
- Описать
class.phpкак ViewModel, связывающий Model (API модулей) и View (шаблон). - Четко разделить: Model = API ядра + доменные сервисы, ViewModel =
class.php, View =template.php. - Добавить раздел о том, как правильно выносить бизнес-логику из
class.phpдля приближения к чистому MVC.
Вариант Б: Дополнение существующей документации
Если сохранение термина MVC принципиально:
- Добавить раздел "Ограничения MVC-реализации в компонентах".
- Описать, что
class.php— это фасад, совмещающий функции контроллера и модели (Fat Controller). - Привести примеры рефакторинга кода из
class.phpв отдельные классы Model.
Пример для иллюстрации проблемы
Текущая документация подразумевает:
User Request → [Controller:class.php] → [Model:API Битрикс] → [View:template.php]
Фактическая архитектура:
User Request → [ViewModel:class.php (получает данные + подготавливает)] → [View:template.php]
↓
[Model:размыта между API ядра и логикой в class.php]
Желаемая архитектура (которую стоит описать в документации):
User Request → [Controller:class.php (thin)] → [Model:Domain Service] → [ViewModel:Presenter] → [View:template.php]
Дополнительный контекст
Эта путаница особенно критична для:
- Разработчиков, переходящих с других фреймворков (Laravel, Symfony), где MVC реализован строго.
- Обучения новых разработчиков: они пытаются применить MVC-шаблоны из документации, получают "божественные" классы в
class.phpи не понимают, где их ошибка. - Поддержки legacy-кода: отсутствие четких архитектурных границ приводит к спагетти-коду в компонентах.
Возможное место в документации
Раздел "Архитектура компонентов" → "Жизненный цикл компонента" или создание отдельного раздела "Архитектурные паттерны в Битрикс Framework".