Comments 10
Здравствуйте, подскажите, пожалуйста, а как в такой структуре взаимодействуете с событиями битрикса? Где-то в структуре их храните и в обработчике указываете метод ? Допустим что-то нужно сделать при смене статуса заказа.
Вообще, изначально, просто использовали кастомную реализацию событий
AddEventHandler - функция предназначена для регистрации произвольных обработчиков, которые не расположены в модулях. Ее необходимо вызывать до возникновения события на тех страницах, где требуется его обработать. Например, если событие нужно обработать на всех страницах, где оно возникает, то функцию можно вызвать в /bitrix/php_interface/init.phpи складывали их в соответствии с архитектурой
но когда время позволяло, то делали полноценную файбрику и в ней регистрировали события, тут на статью тянет))
Создаем фабрику, которая наследует битриксовый контейнер и предоставляет нам методы регистраций событий
Прописываем события, чтобы они зарегистрировались
Ну и сами события регистрируются с помощью функционала \Bitrix\Crm\Service\Operation\<Add,Update...>
Первый вариант, конечно проще, второй универсальнее. Если есть интерес, то могу попросить коллегу, написать отдельную статью по такому подходу.
Спасибо. Было бы очень интересно. Еще хотелось бы про взаимодействие с ORM битрикса в данной архитектуре, интересно как выглядят классы в Models.
И если пишите тесты, то интересно как тестируете допустим создание заказа, smoke тесты или иначе?
По поводу взаимодействия с ОРМ.
Есть как хотелось бы: сделать отдельный сервис в инфраструктуре, в котором был бы паттерн адаптер, которому присылаешь SQL или запрос типа GetList. и он сам бы в зависимости от подключенной ОРМ (Bitrix, Eloquent, doctrine) и т д, формировал бы запрос, ну или хотябы прямые sql, которые просто пернаправлялись в соответствующую ормку.
И есть, как есть: сейчас ОРМ жестко завязана на битрикс, тк в init.php ядро подключается, то и битрикс методы доступны, а далее дело техники, лишь бы через ядро D7, что хоть как-то ложится в архитектуру без кучи глобалов и констант. Про этот вариант можно прочитать в прошлой статье
Тесты, хочется и колется, тк заказная разработка а не внутренняя, и время дается на конкретные задачи, клиент в 90% случаев не выделяет время на них, архитектурно - основу положили, но дальше ждем у моря погоды.
Для примера сделали тест для интеграции с airflow, также из другой прошлой статьи, большего пока позволить не можем себе))
контроллеры у вас битриксовые используются ?
use Bitrix\Main\Engine\Contract\Controllerable;
use Bitrix\Main\Engine\Controller;
Пока да, позиция такая, что нам достался старый проект, который постепенно по кусочку выносим во внешнюю архитектуру, позадачно, с чем работаем - то и выпиливаем.
может быть подскажите решение, чтобы можно было любой неймспейс использовать для контроллеров, дело в том, что по дефолту в router_index есть вызов - Loader::requireClass($controllerClass); который разбивает неймспейс на части и пытается найти модуль, кидает ошибку There is no "тут неймспейс полный" class, module "первые 2 части неймспейса" is unavailable.
Делать модулями не хочется, пока что решил просто левым нейспейсом из одного слова, который не соответствует тому, что прописан в composer
В принципе, в начале статьи, мы просто кастомную папку внутри local. и там контроллеры и любые классы могут использовать иерархию какую пожелаете, лишь бы она была на основе psr-4. Если я правильно понял корень проблемы - в init.php
/*****
* Подключение кастомных классов.
*****/
try {
Loader::registerNamespace(
"MyNameSpace",
Loader::getDocumentRoot() . "/local/Directory"
);
} catch (LoaderException $e) {
echo $e->getMassage();
}Тогда можно будет любой MyNameSpace/Controllers/ControllerClass.php использовать
[Записки тимлида] Битрикс: от модулей к сервисам 2