Кастомные ORM-обработчики для 1С-Битрикс: разработка и аудит

ORM-события в 1С-Битрикс: кастомные обработчики

Представьте проект с каталогом на 50 000 товаров в инфоблоке. Каждое сохранение элемента запускает старые события OnBeforeIBlockElementUpdate и OnAfterIBlockElementUpdate. Они срабатывают при любом изменении через API, админка тормозит в два раза. Выход — ORM-события, привязанные к конкретному DataManager. Они срабатывают только при вызовах add(), update(), delete(). Такой подход точечно реагирует на изменения и снижает нагрузку на 40%. Мы разрабатываем такие обработчики под ключ: от простого аудита до каскадных операций с десятками сущностей. Работаем с инфоблоками, HL-блоками, заказами, пользователями. Сертифицированные специалисты с семилетним стажем. Напишите нам — оценим ваш проект и предложим реалистичные сроки.

Кастомный обработчик напоминает триггер в базе данных, но с возможностью гибкой модификации полей. ORM (object-relational mapping) в Битрикс реализован через классы-наследники DataManager. Каждая операция с записью порождает события до и после действия.

Как устроены события ORM?

У каждого DataManager-класса четыре точки жизненного цикла: добавление, обновление, удаление. Для каждой — before и after. Событие формируется по шаблону {ClassName}::On{Action}. Например, для Bitrix\Sale\Internals\OrderTable событие перед добавлением — Bitrix\Sale\Internals\OrderTable::OnBeforeAdd.

Регистрация стандартная:

use Bitrix\Main\EventManager;

EventManager::getInstance()->addEventHandler(
    'sale',
    '\Bitrix\Sale\Internals\OrderTable::OnAfterAdd',
    [\MyProject\Handlers\OrderOrmHandler::class, 'onAfterAdd']
);

Пошаговая регистрация ORM-обработчика

1. Создайте класс-обработчик с публичными статическими методами.
2. В методе OnBeforeAdd или OnAfterAdd обработайте событие.
3. Для before-событий возвращайте EventResult с модифицированными полями.
4. Для after-событий возврат не требуется, но можно логировать.
5. Зарегистрируйте обработчик через EventManager::addEventHandler.
6. Проверьте, что операция вызывается через ORM (DataManager::add()), а не старый API.

При регистрации важно указать точное полное имя класса с неймспейсом.

Объект события и доступные данные

В обработчик передаётся объект \Bitrix\Main\Entity\Event. Из него извлекаются параметры:

public static function onAfterAdd(\Bitrix\Main\Entity\Event $event): void
{
    $result = $event->getParameter('result');   // объект Result с ID
    $fields = $event->getParameter('fields');   // массив сохранённых полей

    $newId = $result->getId();
    $userId = $fields['USER_ID'] ?? null;
}

Для Before-событий можно модифицировать поля через EventResult:

public static function onBeforeAdd(\Bitrix\Main\Entity\Event $event): \Bitrix\Main\Entity\EventResult
{
    $result = new \Bitrix\Main\Entity\EventResult();
    $result->modifyFields(['CREATED_BY' => \CUser::GetID()]);
    return $result;
}

Типичные ошибки при регистрации ORM-событий

Самая частая — неправильное имя класса или опечатка в операции. Вторая — регистрация на событие, которое не сработает из-за использования старого API. Проверяйте: если данные вставляются через CIBlockElement::Add, ORM-событие не вызовется. Всегда тестируйте обработчик на реальных данных, имитируя нагрузку в 10 000 записей. Третья ошибка — забывают возвращать EventResult в before-событиях. Без этого операция выполнится без изменений.

Практические сценарии

Аудит изменений. Логируем, кто и когда изменил запись в кастомной HL-таблице. Вместо кода — просто факт: записываем в таблицу аудита с идентификатором сущности, пользователем и сериализованными изменениями. Это помогает отследить, кто испортил данные.

Автозаполнение полей. При добавлении записи автоматически проставляем поля: дата создания, статус, хеш.

public static function onBeforeAdd(\Bitrix\Main\Entity\Event $event): \Bitrix\Main\Entity\EventResult
{
    $result = new \Bitrix\Main\Entity\EventResult();
    $result->modifyFields([
        'CREATED_AT' => new \Bitrix\Main\Type\DateTime(),
        'STATUS'     => 'DRAFT',
        'HASH'       => md5(uniqid('', true)),
    ]);
    return $result;
}

Каскадное удаление. Перед удалением основной записи чистим связанные данные. Например, при удалении заказа удаляем его позиции. ORM не делает это автоматически, обработчик поддерживает целостность.

Почему ORM-события лучше старых?

Важный нюанс: если запись создаётся через прямой SQL или старый API, ORM-события не срабатывают. Они работают только при вызовах DataManager::add(), update(), delete().

Почему ORM-события критичны для высоконагруженных проектов?

На сайтах с миллионами записей каждое лишнее срабатывание увеличивает время отклика. ORM-события реагируют только на нужные изменения, снижая нагрузку. Мы оптимизируем каждый обработчик: тегированное кэширование, минимизация запросов к БД, индексы. На одном проекте после миграции на ORM-события время сохранения товара сократилось на 40%. Окупаемость — за 2 месяца сокращения времени загрузки.

Highload-блоки и ORM-события

Для HL-блоков класс DataManager генерируется динамически. Найдите класс:

$hlblock = \Bitrix\Highloadblock\HighloadBlockTable::getById($hlId)->fetch();
$entity = \Bitrix\Highloadblock\HighloadBlockTable::compileEntity($hlblock);
$className = $entity->getDataClass();

Затем зарегистрируйте обработчик на этот класс. Для нескольких HL-блоков создайте универсальный маршрутизатор.

Что входит в разработку обработчиков?

• Анализ текущей событийной модели и схемы данных
• Проектирование структуры обработчиков с учётом бизнес-логики
• Реализация на ORM D7 с нагрузочным тестированием (10 000 событий за минуту)
• Документация по каждому обработчику: схема, параметры, примеры
• Гарантия 6 месяцев на код и поддержка после сдачи

Сроки

Примеры основаны на официальной документации 1С-Битрикс: ORM D7.

Закажите разработку под ключ

Мы реализовали более 50 проектов по 1С-Битрикс. Используем ORM D7, тегированное кэширование, событийную модель. Свяжитесь с нами — получите консультацию и точную оценку вашего проекта. Пишите прямо сейчас.