Варианты реализации своей сущности

Урок 1 из 9

7 мин

Если в «1С-Битрикс: Управление сайтом» нет подходящей готовой сущности, то нужно будет создать свою собственную. Для этого в фреймворке предусмотрено 3 разных механизма, каждый со своими особенностями и пригодный для определенных задач.

  1. Инфоблоки.
  2. Highload-блоки (или HL-блоки).
  3. Собственные таблицы и 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-сущность может создать только разработчик. После создания таблицы в БД требуется объявить класс этой сущности. Главные требования к структуре класса:

  1. Наследовать Bitrix\Main\Entity\DataManager или \Bitrix\Main\ORM\Data\DataManager
  2. Определить имя таблицы в методе getTableName()
  3. Определить структуру таблицы в методе getMap()

Это неочевидно, но фреймворк допускает объявление собственного класса для работы со штатными таблицами, созданными при установке продукта. Но необходимо отдавать себе отчет и четко представлять, зачем это сделано. Мы не рекомендуем злоупотреблять этим приемом. Основная причина для создания собственного ORM-класса для стандартной таблицы — более гибкие и управляемые SQL SELECT-запросы.

В системе есть возможность автоматической генерации такого класса. Этот генерируемый код намеренно избыточен. Всегда просматривайте его перед включением в проект!

Впоследствии, работая с ORM-классом и получая записи из БД, у разработчика будет выбор, как работать с результатом SQL-запроса:

  1. как с ассоциативным массивом;
  2. как с Объектом-наследником Bitrix\Main\ORM\Objectify\EntityObject;
  3. как с Коллекцией — объектом-наследником 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 способа подключить обработчик:

  1. Внутри класса, объявив метод OnBefore/On/OnAfter + Add/Update/Delete
  2. Снаружи класса, через \Bitrix\Main\ORM\EventManager::getInstance()

Подробнее о возможностях ORM-классов читайте в документации.