Внедрение ORM в CMS — тема, где обычно сразу включают режим «будет медленно». Я в таких кейсах всегда смотрю н

Внедрение ORM в CMS — тема, где обычно сразу включают режим «будет медленно». Я в таких кейсах всегда смотрю не на название технологии, а на то, как она ложится в архитектуру и где именно возникает лишняя нагрузка.

Doctrine в ядре WordPress — интересный пример именно по этой причине. Если ORM подключают бездумно, она превращается в слой абстракции ради абстракции: больше объектов, больше запросов, больше памяти. Но если разнести ответственность, держать под контролем загрузку сущностей и не тащить ORM туда, где достаточно прямого SQL, можно получить управляемую модель данных без заметной просадки по производительности.

Схема здесь простая:
legacy-ядро → слой доступа к данным → Doctrine → изолированные сущности и репозитории.
Ключевой момент — не «переписать всё», а встроить ORM точечно, там, где она даёт дисциплину в коде и предсказуемость в сопровождении.

Для проектов на Битрикс это знакомая логика. Не вся интеграция должна жить в высокоуровневой абстракции. Иногда правильнее оставить быстрый прямой доступ, а ORM использовать только для тех зон, где важны структура, тестируемость и контроль над доменной моделью. Именно так обычно и удаётся не убить производительность ради красивого слоя.