Pull to refresh

Comments 14

Рассматривался, тем более это один из вариантов установки zend-expressive. Возможно, из-за его «не впечатляющей» документации он рассматривался не столь пристально. В целом его синтаксис выглядит менее приятно, чем в том же league/container (кажутся излишними lazy, lazyArray, lazyCallable, lazyGet, lazyGetCall, lazyNew, lazyValue...). Из коробки DelegateContainer может быть один(не массив). Также на беглый взгляд плохи дела с сервис провайдерами.
Документация вполне подробная, вроде все четко описано. lazy-функционал для экономии ресурсов очень полезен, особенно когда у вас куча сервисов с кучей зависимостей — инициализируете только то что нужно
Так же можете создавать отдельные конфиги для каждого модуля/бандла/компонента приложения, есть некоторое сходство с сервис-провайдерами
Сравните опыт работы c документацией League и Aura.Di. Я не спорю, что документация есть, я говорю о том, что она может быть в разы лучше. В League контейнере все из коробки lazy (думаю так обстоят дела во всех современных контейнерах), префикс lazy кажется атавизмом.
В любом случае ваш выбор упадет на то, с чем вы раньше работали. И если у вас удачный опыт работы с Aura.Di — лучше работать с ним дальше.
Статья еще раз убеждает следовать принципу: детали должны зависеть от абстракций. В нашем конкретном примере от интерфейса контейнера.
Да, оба контейнера используют container-interop, так что все утыкается в субъективное удобство в данном случае
Мне кажется, вы говорите про загрузку по требованию, а MetaDone про ленивую инъекцию.

Ленивая инъекция невозможна по умолчанию, т.к. обычно она работает через наследование.
Серьезный выбор был между двумя микро-фреймворками: Slim и Zend.

Zend микро-фреймворк, простите?
Благодаря модульной архитектуре zend-expressive намного больше «Микро», чем тот же Lumen. Сравните его лист requirements github.com/zendframework/zend-expressive/blob/master/composer.json#L29-L35. В минимальной инсталляции в нем идет только контейнер, роутер и pipeline — не больше, чем в Slim.
Затем я переключился на Slim. Его внедрение в проект заняло меньше дня. Выбор контроллеров (старого и новго образца) был реализовано через middleware. На Slim и остановился. В далеких планах перейти на pipeline с PSR-15 middleware.

Не могли бы показать, как было и как стало? Не очень понимаю, как у вас роутинг и на новые контроллеры и на старые сделан.
Роутинг на новые контроллеры работает через FastRoute. Если роут в FastRoute не найден, тогда я отдаю выполнения приложения старому коду (который обрабатывал запросы раньше). Если роут найдет — выполняется Slim приложение.

<?php

// Middleware, решающее какой контроллер нужно выполнить.
class ControllerDispatcherTypeMiddleware
{
    // Была написана обертка над старым роутингом.
    public function __construct(LegacyControllerDispatcher $legacyControllerDispatcher)
    {
        $this->legacyControllerDispatcher = $legacyControllerDispatcher;
    }

    public function __invoke($request, $response, $next)
    {
        $routeInfo = $request->getAttribute('routeInfo');

        // Если роут не найдем в роутинге приложения Slim, тогда отправляем запрос в старый обработчик.
        if ($routeInfo[0] === \FastRoute\Dispatcher::NOT_FOUND) {
            // Вызов "старых" контроллеров
            $this->legacyControllerDispatcher->dispatch();
        }

        // Стандартная работа Slim приложения
        return $next($request, $response);
    }
}

//Регистрируем выбор типа контроллеров первым Middleware в приложении
$app = new \Slim\App();
$app->add(ControllerDispatcherTypeMiddleware::class);
Silex полностью завязан на компоненты Symfony и Pimple, легко в нем компоненты не заменишь.
Вопрос по поводу контейнера. А на php-di не смотрели? И если смотрели, то почему его не взяли?
Php-Di рассматривался, но каких то киллер-фич в нем не вижу. А синтаксис League контейнера кажется приятнее (это, конечно же, мое субъективное мнение).
Sign up to leave a comment.

Articles