Компоненты Битрикс: 1.0 и 2.0

Компонент — это базовый строительный блок вывода данных в 1С-Битрикс. Понимание разницы между версиями 1.0 и 2.0 помогает читать чужой код, поддерживать старые проекты и грамотно строить новые без смешивания логики и вёрстки.

Что такое компонент и зачем он нужен

Компонент в 1С-Битрикс — это переиспользуемый программный модуль, который извлекает данные из инфоблоков, пользователей, заказов и других сущностей и передаёт их в шаблон для вывода. Он инкапсулирует бизнес-логику и отделяет её от HTML-разметки страницы.

Физически любой компонент лежит в каталоге /bitrix/components/ (системные) или /local/components/ (кастомные), сгруппированный по пространствам имён вида namespace:component.name, например bitrix:news.list.

• компонент отвечает за выборку и подготовку данных;
• шаблон компонента — за их отображение;
• параметры — за настройку поведения без правки кода.

Компоненты 1.0: как это работало

Первое поколение компонентов появилось в ранних версиях продукта. Это был просто PHP-файл, который подключался директивой #OBJECT_ID# через визуальный редактор или напрямую через <?$APPLICATION->IncludeFile(...)?>. Логика выборки и HTML-вёрстка находились в одном файле.

Такой подход имел серьёзные недостатки:

• невозможно отделить дизайн от логики — правка вёрстки затрагивала запросы к БД;
• нет встроенного кэширования результата;
• сложно переиспользовать один и тот же вывод с разным оформлением;
• обновление продукта могло затирать пользовательские изменения.

Компоненты 2.0: разделение логики и представления

Второе поколение принесло чёткое разделение ответственности. Логика вынесена в файл component.php, а вывод — в отдельные шаблоны в каталоге templates/. Между ними стоит стандартизированный массив $arResult.

Компонент 2.0 умеет:

• кэшировать результат выборки через $this->StartResultCache() и $this->EndResultCache();
• принимать параметры через массив $arParams с описанием в .parameters.php;
• иметь несколько независимых шаблонов;
• работать в составе комплексных компонентов с ЧПУ.

Вызов компонента 2.0 выглядит так:

$APPLICATION->IncludeComponent('bitrix:news.list', '.default', array('IBLOCK_ID' => 5, 'CACHE_TIME' => 3600));

Сравнение 1.0 и 2.0

Ключевые различия удобно свести в таблицу.

Структура компонента 2.0 на диске

Стандартный набор файлов компонента выглядит так:

• component.php — логика: выборка данных, формирование $arResult;
• .parameters.php — описание параметров для интерфейса настройки;
• .description.php — название, описание и раздел компонента в дереве;
• class.php — класс компонента (для компонентов, наследующих CBitrixComponent);
• templates/.default/template.php — шаблон вывода по умолчанию.

Жизненный цикл вызова

При вызове IncludeComponent() ядро выполняет цепочку действий:

1. инициализирует объект компонента и подготавливает $arParams;
2. исполняет component.php — здесь идёт проверка кэша и выборка данных;
3. формирует итоговый $arResult;
4. подключает result_modifier.php шаблона, если он есть, для донастройки данных;
5. исполняет template.php для генерации HTML;
6. подключает component_epilog.php — код, который должен исполняться и при попадании в кэш.

Понимание этой последовательности критично: например, эпилог используют для установки заголовков страницы и хлебных крошек, потому что он работает даже когда основной результат взят из кэша. Если поместить установку SetTitle() внутрь template.php, то при попадании в кэш этот код не исполнится и заголовок собьётся.

Отдельно стоит понимать, где проходит граница кэша. Всё, что находится между startResultCache() и endResultCache(), а также вывод шаблона попадают в файл кэша. Эпилог и то, что вы явно вынесли через отложенные функции, исполняются при каждом запросе. Именно поэтому в компонентах 2.0 динамические элементы вроде корзины или блока авторизации либо грузят через AJAX, либо помечают некэшируемыми — иначе они «замёрзнут» в закэшированной странице.

Миграция и поддержка старого кода

Если проект содержит компоненты 1.0, полностью переписывать их сразу не всегда рационально. Разумная стратегия:

• инвентаризировать все места вызова через IncludeFile и старые директивы;
• заменять их на аналоги 2.0 (например, самописный вывод новостей — на news.list со своим шаблоном);
• выносить бизнес-логику в отдельные классы и сервисы, а не размазывать по шаблонам;
• обязательно включать кэширование там, где данные меняются нечасто.

Отдельная сложность наследуемых проектов — прямые SQL-запросы и вызовы CDatabase внутри вёрстки. При переводе на 2.0 такие места сначала оборачивают в понятные методы выборки, затем добавляют кэширование, и только потом занимаются оформлением. Такой порядок снижает риск регрессий: сначала стабилизируется логика и производительность, а вёрстка меняется в последнюю очередь, когда данные уже приходят в предсказуемом виде через $arResult.

Итог

Компоненты 1.0 — исторический этап без разделения логики и вёрстки и без кэширования; сегодня они встречаются только в наследуемых проектах. Компоненты 2.0 — актуальный стандарт с чёткой структурой файлов, управляемым кэшем, параметрами и поддержкой ЧПУ. Знание жизненного цикла вызова — от component.php до эпилога — необходимо, чтобы писать быстрый и поддерживаемый код.

Если вам нужно навести порядок в наследуемой кодовой базе, перевести старые компоненты на современную архитектуру или спроектировать масштабируемое решение с нуля, мы помогаем с этим в рамках разработки архитектуры сложных проектов и поддержки.