В битриксе есть замечательная универсальная сущность – инфоблок, с помощью которой удобно хранить и структурировать различные данные. Но вот работать с универсальными данными не всегда удобно. Для реализации бизнес-логики предпочтительнее оперировать специальными объектами и при этом хранить данные, конечно, в инфоблоках.
Создавая очередной класс некой сущности, делая в нем getList и getById, и реализуя кеширование данных – захотелось как то унифицировать этот процесс.
Идея была воплощена в виде универсальных классов для инфоблоков. Здесь я не буду останавливаться на их реализации – это можно сделать . Опишу применение, чтобы можно было оценить удобство работы.
Основные операции с элементами для чтения - это получение списка с определенной сортировкой и фильтром, а также получение элемента по ИД, как частный случай.
Мы создаем для каждой сущности класс, являющийся наследником базового класса, устанавливая у него значение свойства ИД инфобока. Например компании:
class MyCompanyElement extends ObjElement {
static $iblock_id = 3;
} |
Чтобы получить элемент типа MyCompanyElement с ИД = 5 нужно использовать метод:
$company = MyCompanyElement::getById(5); |
Чтобы получить список активных элементов инфоблока, отсортированных, например, по имени – нужно использовать метод:
$list = MyCompanyElement::getList(array('NAME' => 'ASC'), array('ACTIVE' => 'Y')); |
Таким образом:
$element = $list[45]; /* элемент типа MyCompanyElement с ИД = 45 */ |
foreach($list as $id => $company) {
/** @var MyCompanyElement $company */
...
} |
Цикл по элементам списка с ключом соответствующим ИД элемента (инфоблока), при этом $element – элемент типа MyCompanyElement.
Обратите внимание на phpdoc конструкцию внутри цикла. Она позволяет для IDE (Php Storm) правильно определять тип и выводить в подсказке все методы класса.
$cnt = count($list); /* количество элементов списка. */ |
Теперь, имея возможность легко создавать классы для сущностей бизнес логики – мы можем реализовать для них различные специфические методы, соответствующие именно этим сущностям.
Представим, что есть инфоблок Employee элементы которого привязаны к элементам инфоблока Company через свойство COMPANY. Создаем класс
class MyEmployeeElement extends ObjElement {
static $iblock_id = 4;
} |
И добавляем метод получения связанных элементов в класс MyCompanyElement
class MyCompanyElement extends ObjElement {
static $iblock_id = 3;
public function getEmployees($sort = array(), $filter = array()) {
$filter['PROPERTY_COMPANY'] = $this->getId();
return MyEmployeeElement::getList($sort, $filter);
}
} |
Тогда получение списка всех сотрудников компании с ИД 5 реализуется как
$company = MyCompanyElement::getById(5); $employees = $company-> getEmployees(); /* объект типа ObjCachedList, содержащий список объектов типа MyEmployeeElement */ |
Классы списков ObjCachedList и ObjCachedSectList реализуют управляемое кеширование элементов и разделов, зависящее от тега “iblock_id_XX”. Так как все операции с инфоблоками кешируются – удобно и легко делать свои простые компоненты на основе . Или не делать компоненты
.Аналогично элементам реализован класс для разделов инфоблоков. Наверное, было бы полезно и для самих инфоблоков, но у меня пока такой потребности не возникло.
Для разделов минимальный код аналогично:
сlass MyCompanySection extends ObjSection {
static $iblock_id = 3;
} |
Идеально для реализации небольших справочников.
Идея классов-сущностей может стать еще полезнее, если сделать в них возможность реализации обработки событий для определенного инфоблока.
Как мне видится – это менеджер событий, при возникновении события определяющий объект какого инфоблока вызвал событие, затем проверяющий для инфоблока с кодом IblockCode наличие класса PrefixIblockCodeElement и в нем соотв. метода, например
PrefixIblockCodeElement:: OnAfterIBlockElementAdd. Ведь практически все обработчики событий инфоблоков сначала определяют какой тип инфоблока вызвал событие, и только потом делают какие то операции.
В этом случае стало бы намного удобнее и логичнее организовывать код обработчиков. .
Скачать базовые классы можно по .
Сейчас сам активно использую эту схему в проекте. Надеюсь на конструктивные замечания и предложения по развитию идеи.
P.S. требование - php не ниже 5.3 и так как классы используют позднее связывание – у меня возникли проблемы с акселератором APC – пришлось его отключить.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
