Розробка ORM-сутностей 1С-Бітрікс D7 під ключ

Розробка ORM-сутностей 1С-Бітрікс D7

Ми більше 10 років працюємо з 1С-Бітрікс і бачимо, як багато проєктів страждає від каші в базі даних: сирі SQL-запити в компонентах, дублювання логіки, відсутність типів. ORM D7 — інструмент, який перетворює хаос на порядок. DataManager-сутність описує таблицю, її поля та зв'язки, а замість $DB->Query ви пишете MyTable::getList([...]). За 10+ років ми реалізували 50+ проєктів на ORM D7 — від невеликих кастомних модулів до повної заміни legacy-схем у каталогах з мільйонами записів.

Чому ORM D7 вигідніше сирих SQL-запитів?

Прямі SQL-запити через $DB->Query — минуле століття. Вони важко підтримуються, не дають типізованих об'єктів і не інтегруються з кешем Бітрікс. ORM D7 вирішує всі ці проблеми: код стає читабельним, безпечним (екранування автоматично), а швидкість розробки зростає у 2–3 рази. Крім того, ORM-сутності вміють працювати з тегованим кешем, який скидається лише при зміні даних, а не за таймером. Це особливо важливо на високонавантажених проєктах.

Базова структура DataManager

Мінімальна сутність виглядає так:

namespace MyProject\Storage; use Bitrix\Main\ORM\Data\DataManager; use Bitrix\Main\ORM\Fields\IntegerField; use Bitrix\Main\ORM\Fields\StringField; use Bitrix\Main\ORM\Fields\DatetimeField; class OrderLogTable extends DataManager { public static function getTableName(): string { return 'my_order_log'; } public static function getMap(): array { return [ new IntegerField('ID', [ 'primary' => true, 'autocomplete' => true, ]), new IntegerField('ORDER_ID', [ 'required' => true, ]), new StringField('ACTION', [ 'required' => true, 'size' => 100, ]), new DatetimeField('CREATED_AT', [ 'default_value' => new \Bitrix\Main\Type\DateTime(), ]), ]; } } 

Клас реєструється в autoload-карті модуля або через PSR-4 у composer.json всередині /local/.

Типи полів ORM

Для валідації полів використовується параметр validation.

Як правильно описати зв'язки в DataManager?

Один-до-багатьох (Reference) описується через Reference із зазначенням класу цільової сутності та умови Join. Після опису зв'язку в запиті ви отримуєте дані joined-таблиці.

$result = OrderLogTable::getList([ 'select' => ['ID', 'ACTION', 'ORDER_.USER_ID', 'ORDER_.DATE_INSERT'], 'filter' => ['ORDER_ID' => 42], ]); 

Створення таблиці: міграції

Таблицю створює метод createDbTable() класу сутності. Для зміни структури — DDL-запити через Application::getConnection(). Бітрікс не має вбудованого механізму міграцій — для продакшн-проєктів це вирішується власним скриптом-мігратором.

ORM-запити: основні операції

Вибірка з умовами:

$result = OrderLogTable::getList([ 'select' => ['ID', 'ORDER_ID', 'ACTION', 'CREATED_AT'], 'filter' => [ '>CREATED_AT' => new \Bitrix\Main\Type\DateTime('-7 days'), 'ACTION' => 'STATUS_CHANGED', ], 'order' => ['CREATED_AT' => 'DESC'], 'limit' => 50, ]); while ($row = $result->fetch()) { } 

Додавання, оновлення та видалення виконуються через методи add(), update(), delete(). ORM автоматично перевіряє типи та екранує значення.

Кешування запитів

ORM інтегрується з кешем Бітрікс:

$result = OrderLogTable::getList([ 'select' => ['ID', 'ACTION'], 'filter' => ['ORDER_ID' => 42], 'cache' => ['ttl' => 3600, 'cache_joins' => true], ]); 

Кеш скидається автоматично при зміні даних через ORM-методи (якщо включено керований кеш).

Строки

DataManager-сутності — це інвестиція в читабельність і підтримуваність коду. Через рік розробник, який не писав цей код, розбереться в схемі БД за годину, а не за день. При роботі з сирим SQL такої гарантії немає.

Що входить в роботу

• Документація по схемі БД — опис таблиць, полів, зв'язків та індексів.
• Вихідний код сутностей — класи DataManager з валідацією та подіями.
• Скрипти міграції — для створення та зміни таблиць, перенесення даних.
• Інструкція з розгортання — порядок встановлення модуля та оновлень.
• Підтримка 2 тижні після здачі — виправлення помилок, консультації.

$conn = \Bitrix\Main\Application::getConnection(); $conn->query("ALTER TABLE my_order_log ADD COLUMN CONTEXT TEXT DEFAULT NULL"); $conn->query("CREATE INDEX idx_order_log_created ON my_order_log (CREATED_AT)"); 

Типові помилки при роботі з ORM D7

• Відсутність індексів — запити гальмують на обсягах від 100 000 рядків.
• Неправильні типи полів — наприклад, StringField замість TextField, що ріже дані.
• Ігнорування кешування — кожен запит б'є в БД, хоча дані рідко змінюються.
• Відмова від зв'язків — ручне підвантаження пов'язаних записів веде до N+1 запиту.

Уникаємо цих грабель за рахунок рев'ю коду та навантажувального тестування.

Як ми впроваджуємо ORM-сутності: реальний кейс

Один з проєктів — інтернет-магазин з каталогом на 300 000 товарів. Спочатку всі вибірки робилися через CIBlockElement::GetList з купою параметрів. Продуктивність впала, сторінки завантажувалися по 5 секунд. Ми розробили ORM-шар для торгових пропозицій, знижок та залишків. Результат: час генерації сторінки списку скоротився до 0,8 секунди, а складний фільтр став оброблятися за 0,3 секунди. Додатково підключили теговане кешування, і кількість запитів до БД впала в 4 рази. В середньому економія бюджету на підтримці таких проєктів становить 30–50%.

Процес роботи

1. Аналітика — вивчаємо структуру поточної БД, бізнес-вимоги та навантаження.
2. Проектування — малюємо схему ORM-сутностей, визначаємо зв'язки та індекси.
3. Реалізація — пишемо код сутностей, методи CRUD, події та кешування.
4. Тестування — юніт-тести, навантажувальне тестування з реальними обсягами.
5. Деплой — застосовуємо міграції, оновлюємо доступи, передаємо документацію.

Зв'яжіться з нами, щоб обговорити ваш проєкт. Оцінимо складність і запропонуємо строки без зайвих зобов'язань. Замовте консультацію вже сьогодні.

Докладніше про ORM читайте на Wikipedia та в офіційній документації 1С-Бітрікс (dev.1c-bitrix.ru).