Если в «1С-Битрикс: Управление сайтом» нет подходящей готовой сущности, то нужно будет создать свою собственную. Для этого в фреймворке предусмотрено 3 разных механизма, каждый со своими особенностями и пригодный для определенных задач.
- Инфоблоки.
- Highload-блоки (или HL-блоки).
- Собственные таблицы и ORM-сущности.
С Инфоблоками вы познакомились в предыдущих уроках и хорошо представляете их базовые возможности: расширяемость за счет свойств, возможность создавать иерархию из разделов, возможность использования во многих других механизмах сайта, таких как поиск и каталог интернет-магазина. Это самый распространенный выбор при разработке сайтов.
Highload-блоки выбирают, когда нужен быстрый плоский (без иерархии) справочник, без тех богатых возможностей, которые замедляют Инфоблоки по сравнению с простой таблицей в БД. При этом в системе по прежнему остается веб-интерфейс для управления данными и метаданными Highload-блоков (расширение за счет UF-свойств).
Если нужна еще большая гибкость — рекомендуется выбирать собственную таблицу БД. У таких сущностей почти нет готовых механизмов, за исключением ORM-класса. Нет поиска, иерархии, прав доступа, веб-интерфейса администратора для добавления записей и импорта из файла. Все нужно будет реализовать самостоятельно.
Критерии сравнения
У каждого варианта реализации есть свои сильные и слабые стороны, выбирать надо разумно исходя из задачи. Например, в Инфоблоках 1.0 нет ограничения на количество свойств, и есть готовый интерфейс администратора. Отлаживать SQL-запросы удобнее в ORM и HL-блоках, но и компоненты придется для них разрабатывать свои.
Большинство ограничений можно обойти (разработать компоненты для ORM, реализовать участие HL-блоков в Поиске, добавить поддержку прав и многосайтовости), кроме SQL-индексов и ограничений на поля в СУБД.
Возможности | Инфоблоки | HL-блоки | Своя таблица и ORM |
---|---|---|---|
Количество полей | ИБ 1.0: Без ограничений ИБ 2.0: 50 |
Ограничено СУБД | Ограничено СУБД |
SQL-индексы | ИБ 1.0: Нет ИБ 2.0: Да |
Да | Да |
Поиск | Да | Нет | Нет |
Многосайтовость | Да | Нет | Нет |
Права доступа | Да, расширенные | Да | Нет |
Готовые компоненты | 10+ | 2 | 0 |
Интерфейс администратора | Да | Да | Нет |
Импорт и экспорт записей | Да | Да | Нет |
Импорт и экспорт структуры | Да | Нет | Нет |
Группировка записей в иерархию | Да | Нет | Нет |
Отладка запросов | Нет | Да | Да |
API с защитой от SQL-инъекций | Да | Да | Да |
ORM
Создание HL-блоков и Инфоблоков производится в административном разделе в визуальном интерфейсе, а ORM-сущность может создать только разработчик. После создания таблицы в БД требуется объявить класс этой сущности. Главные требования к структуре класса:
- Наследовать Bitrix\Main\Entity\DataManager или \Bitrix\Main\ORM\Data\DataManager
- Определить имя таблицы в методе getTableName()
- Определить структуру таблицы в методе getMap()
Это неочевидно, но фреймворк допускает объявление собственного класса для работы со штатными таблицами, созданными при установке продукта. Но необходимо отдавать себе отчет и четко представлять, зачем это сделано. Мы не рекомендуем злоупотреблять этим приемом. Основная причина для создания собственного ORM-класса для стандартной таблицы — более гибкие и управляемые SQL SELECT-запросы.
В системе есть возможность автоматической генерации такого класса. Этот генерируемый код намеренно избыточен. Всегда просматривайте его перед включением в проект!
Впоследствии, работая с ORM-классом и получая записи из БД, у разработчика будет выбор, как работать с результатом SQL-запроса:
- как с ассоциативным массивом;
- как с Объектом-наследником Bitrix\Main\ORM\Objectify\EntityObject;
- как с Коллекцией — объектом-наследником Bitrix\Main\ORM\Objectify\Collection.
Большая часть методов Объекта и Коллекции - виртуальные, обрабатываются через магический метод __call. Для удобного их использования в IDE с функцией автодополнения по мере набора текста, рекомендуется сгенерировать аннотации командой orm:annotate (подробнее в документации).
API для CRUD
5 базовых методов для 4-х основных операций работы с данными (CRUD):
- C (Create)
- add(array $data): \Bitrix\Main\Entity\AddResult
- R (Read)
- getById(mixed $id): \Bitrix\Main\DB\Result
- getList(array $parameters = array()): \Bitrix\Main\DB\Result
- U (Update)
- update(mixed $primary, array $data): \Bitrix\Main\Entity\UpdateResult
- D (Delete)
- delete(mixed $primary): \Bitrix\Main\Entity\DeleteResult
Все операции манипуляции с данными используют механизм обработчиков событий, чтобы у разработчиков была возможность вмешаться в процесс. Есть 2 способа подключить обработчик:
- Внутри класса, объявив метод OnBefore/On/OnAfter + Add/Update/Delete
- Снаружи класса, через \Bitrix\Main\ORM\EventManager::getInstance()
Подробнее о возможностях ORM-классов читайте в документации.