Розробка компонента 1С-Бітрікс
Стандартні компоненти Бітрікс покривають 80% типових задач. Але коли потрібні специфічні списки з фільтрацією за багатьма параметрами, складні форми з AJAX-валідацією або інтеграція з зовнішнім API — без власного компонента не обійтися. Типова помилка новачка — писати логіку прямо в шаблоні або копіювати код з component.php у кожен новий проект. Це призводить до дублювання, труднощів підтримки та проблем з кешуванням.
Уявіть каталог на 100 000 товарів з 20 властивостями фільтра — стандартний bitrix:catalog не справляється. Без кеша база падає, з кешем дані застарілі. Наш підхід — будувати компонент з правильною архітектурою, використовуючи теговане кешування та перевикористовувані класи. Ми за понад 10 років розробили більше 50 компонентів — від каталогів інтернет-магазинів до корпоративних порталів, кожен за правилами шаблону проєктування «Модель-Представлення».
Проблеми, які вирішуємо
- Відсутність кешування. Без кеша кожен виклик компонента робить запити до БД. При 1000 відвідувачів це дає навантаження 10 000 запитів на хвилину. Правильний кеш знижує його до 1–2 запитів на період кешування.
- Жорсткий зв'язок логіки та шаблону. Коли запити в template.php, дизайнер не може змінити верстку, не ризикуючи зламати код. Розділення шарів вирішує це на 100%.
- Проблеми з інвалідацією кеша. Скидання всього кеша при зміні одного елемента — марна трата ресурсів. Теговане кешування, реалізоване через
\Bitrix\Main\Data\TaggedCache, оновлює лише потрібні записи та економить до 40% часу завантаження сторінки. - Відсутність нормалізації параметрів. Параметри, передані в
$arParams, можуть бути невалідними. МетодonPrepareComponentParams()у класі компонента гарантує коректні значення.
Як ми це робимо: стек та конфіги
Ми використовуємо PHP 8.1+, інфоблоки v2.0, ORM Бітрікс, модуль main. Для типового компонента (список елементів) пишемо клас, що успадковує CBitrixComponent. В onPrepareComponentParams приводимо IBLOCK_ID до int, COUNT — до додатного числа. Потім в executeComponent вмикаємо кеш, отримуємо дані через CIBlockElement::GetList з сортуванням та фільтром. Результат збираємо в $arResult['ITEMS']. Шаблон містить лише HTML та виклик AddCss/AddJs через Asset.
Кейс із практики. Для інтернет-магазину з каталогом 50 000 товарів потрібен був компонент фільтрації за 12 параметрами. Ми реалізували класовий компонент з тегованим кешем і подією OnAfterIBlockElementUpdate для інвалідації. Після впровадження навантаження на сервер знизилося на 35%, а час відгуку — з 2 секунд до 0.4 секунди.
Процес роботи
- Аналітика — вивчаємо архітектуру, навантаження, вимоги.
- Проєктування — визначаємо структуру, параметри, кеш, інтеграції.
- Реалізація — пишемо клас, шаблон, тести.
- Тестування — навантажувальне, функціональне, на сумісність з оновленнями.
- Деплой — встановлення на бой, передача документації.
Строки розробки
| Тип компонента | Що входить | Строк |
|---|---|---|
| Простий (список, детальна) | Логіка + шаблон + параметри + кеш | 2–5 днів |
| Середній (AJAX, форма, події) | + обробка POST, події, інвалідація | 1–2 тижні |
| Комплексний (клас, кілька шаблонів) | + ORM, дочірні компоненти, права | 2–4 тижні |
Вартість розраховується індивідуально під завдання — зв'яжіться для точної оцінки.
Чому варто використовувати клас замість процедурного коду?
Класовий підхід у 2 рази скорочує час налагодження та на 30% спрощує підтримку при оновленнях. Це підтверджує наш досвід: у проектах з класами кількість багів в середньому на 40% менше. Порівняння:
| Критерій | Процедурний (component.php) | Класовий (class.php) |
|---|---|---|
| Нормалізація параметрів | Вручну на початку файлу | onPrepareComponentParams() |
| Розширюваність | Модифікація файлу | Успадкування та перевизначення методів |
| Тестованість | Низька | Висока |
| Час налагодження | Базовий | Скорочується вдвічі |
Як правильно налаштувати кешування компонента?
Використовуйте $this->StartResultCache() та $this->EndResultCache(). Для інвалідації при зміні даних — BXClearCache(true, '/cache/path/') в події OnAfterIBlockElementUpdate. Точніше працює теговане кешування: TaggedCache::startTagCache('my_tag'); ... TaggedCache::endTagCache(). Воно дозволяє скинути лише записи, пов'язані з конкретними елементами, а не весь кеш компонента. Таке налаштування прискорює інвалідацію в 5 разів порівняно зі скиданням всього кешу.
Приклад тегованого кешування в коді
<?php use Bitrix\Main\Data\TaggedCache; $taggedCache = TaggedCache::getInstance(); $taggedCache->startTagCache('/my/component/'); $taggedCache->registerTag('iblock_id_3'); // ... запити та формування $arResult $taggedCache->endTagCache(); ?> При зміні елемента інфоблоку з id=3 кеш буде скинуто автоматично.
Що входить у нашу роботу
- Повний аудит поточної архітектури та формування ТЗ.
- Розробка компонента з урахуванням кешування, подій, багатосайтовості.
- Документація з використання та доопрацювання.
- Тестування на навантаження та сумісність.
- Передача прав на компонент та навчання вашої команди.
- Підтримка 30 днів після здачі.
- Гарантія окупності — типовий компонент окупається за 3 місяці за рахунок зниження витрат на підтримку.
Компонент, написаний за правилами шаблонів проєктування, легко переносити між проектами та кастомізувати без зміни ядра. Наш досвід гарантує стабільну роботу на роки.
Отримайте консультацію по вашому проекту — ми безкоштовно оцінимо складність та запропонуємо оптимальний підхід. Замовте розробку компонента, і ми гарантуємо результат, що відповідає стандартам платформи, та окупність ваших інвестицій. Детальна документація — на dev.1c-bitrix.ru.