Comments 4
Правильной дорогой идёте, товарищи, жаль что поздновато
Это, конечно, всё очень интересно, но когда вы уберёте final с фабрик стандартных CRM сущностей? Когда вы исправите массовое помещение элементов смарт-процессов в поисковый индекс? Когда действие, производящее обратно-совместимое событие, перестанет собирать по-новой массив на основе экземпляра Item для каждого из обработчиков? Когда конвертеры TaskToTemplate и TemplateToTask перестанут делать вещи, обратные их наименованию? Когда в валидаторе имени модуля для b_disk_storage будет исправлено регулярное выражение, не позволяющее разработчикам добавлять собственные дисковые хранилища? Когда в сборщике доступных в БП функций появится событие, отмеченное как // TODO: send Event? Когда в шаблоне компонента bitrix:ui.tile.list будет исправлено наименование параметра bgColor, не позволяющее изменять фон ячейки? Когда создание пользовательского поля типа "дата-время" перестанет ломать карточку рабочих групп? Когда модуль pull перестанет делать запросы в цикле для того, чтобы узнать список всех существующих приватных каналов получателей пулл события? Когда в интерфейсах "ролевой модели" модуля main исчезнут конструкторы, лишающие реализацию гибкости? Когда появится возможность сохранять .settings.php для конкретных модулей? Когда появится возможность копировать объект \Bitrix\Main\ORM\Query\Query без потери данных от оригинального объекта? Когда появится возможность переиспользования Query в целом? Когда в команду orm:annotate будет добавлена возможность присоединять php-doc аннотации к дата-менеджерам, а не генерировать один огромный orm meta файл? Когда появится адекватная сборка мусора в фабриках CRM сущностей? Когда коробочная версия Битрикс24 начнёт поддерживать мультиязычность? Когда модуль задач обретёт единое API, которое не сводится к вызовам CTasks?
Ближайшее, что смог вспомнить.
Может быть, стоит собрать фидбэк разработчиков и поправить известные ошибки перед тем, как добавлять узконаправленную функциональность?..
Для начала вспомним, что контроллеры — это часть MVC архитектуры, которая отвечает за обработку запроса и генерирование ответа.
Вы же даже ссылку на вики привели, карл! Контроллер отвечает за получение событий (да пусть даже тех же Реквестов, сделаем скидку на веб-специфику) юзера и обновление моделей. Прям почти цитата из вашей ссылки.
А за обработку запроса (события) и генерацию ответа (представления) отвечает MVP
В остальном молодцы, сделали почти как в Symfony/Yii 15-ти летней давности (в ларке миддлвари), за исключением того, что вместо "событий" (если говорить про Symfony) используются "фильтры". Имхо, это намного лучше именование, чем "события" в симфе, т.к. последние иммутабельными должны быть. Тут грамотно.
Далее, наличие createFromRequest метода - это уже скорее не DTO, а ValueObject. Думаю не особо критично, но нейминг мне кажется не совсем корректный. Или я ошибаюсь? Всё же это статический конструктор... Однако всё же фабричный, а DTO не должно содержать никакой логики вообще.
P.S. В целом, то что битрикс превращается во что-то более-менее терпимое -- это безусловно плюс, однако как всегда - остаётся ощущение, что с точки зрения архитектуры/проектирования опять недоделали и это в перспективе опять вызовет проблемы:
У вас есть атрибуты в которых есть объекты. Если "фильтр" -- это полноценный сервис (например CSRF), то ему требуется ссылка на сессию, энкриптер и прочие инфраструктурные сервисы. Однако вы по-определению таким способом декларации (внутри метод getFilters) запрещаете использовать DI, что требует декларации подобных штук как синглтонов (?), что опять превращает всё в набор из глобального стейта. В корректной реализации getFilters должен возвращать или название сервиса из контейнера, или вызывать какой-то метод, передавая туда настройки из атрибута.
Вначале статьи вы ссылаетесь на статью, где подробно описано как можно внедрять параметры из запроса. Однако там хардкод на имя класса, но ни слова о внедрении на основе имени переменной, на основе интерфейса, на основе атрибута и прочих. При этом это всё прибито гвоздями к контроллеру. Что делать в том случае, если логку (класс) для внедрения надо расшарить на несколько контроллеров? А что, если там более сложная логика, например внедрение соединения к БД на основе объекта запроса (
WeakMap<Request, ConnectionInterface>, коннекшн пул и все дела)? Я вообще не вижу там никакой возможности получения сервисов (DI) и информации о текущем состоянии (запросе).
В общем, шаги верные, вы молодцы. Однако архитектурно новый код ограничивает и плохо спроектирован. Выглядит как ранняя альфа, которая требует переделывания/доработок с поломкой обратной совместимости.
Спасибо, будем иметь ввиду (͡°͜ʖ͡°)
Новое в контроллерах Bitrix Framework: фильтры и валидация