Comments 14
В качестве di-контейнера не рассматривали https://github.com/auraphp/Aura.Di?
Рассматривался, тем более это один из вариантов установки zend-expressive. Возможно, из-за его «не впечатляющей» документации он рассматривался не столь пристально. В целом его синтаксис выглядит менее приятно, чем в том же league/container (кажутся излишними lazy, lazyArray, lazyCallable, lazyGet, lazyGetCall, lazyNew, lazyValue...). Из коробки DelegateContainer может быть один(не массив). Также на беглый взгляд плохи дела с сервис провайдерами.
Документация вполне подробная, вроде все четко описано. lazy-функционал для экономии ресурсов очень полезен, особенно когда у вас куча сервисов с кучей зависимостей — инициализируете только то что нужно
Так же можете создавать отдельные конфиги для каждого модуля/бандла/компонента приложения, есть некоторое сходство с сервис-провайдерами
Так же можете создавать отдельные конфиги для каждого модуля/бандла/компонента приложения, есть некоторое сходство с сервис-провайдерами
Сравните опыт работы c документацией League и Aura.Di. Я не спорю, что документация есть, я говорю о том, что она может быть в разы лучше. В League контейнере все из коробки lazy (думаю так обстоят дела во всех современных контейнерах), префикс lazy кажется атавизмом.
В любом случае ваш выбор упадет на то, с чем вы раньше работали. И если у вас удачный опыт работы с Aura.Di — лучше работать с ним дальше.
Статья еще раз убеждает следовать принципу: детали должны зависеть от абстракций. В нашем конкретном примере от интерфейса контейнера.
В любом случае ваш выбор упадет на то, с чем вы раньше работали. И если у вас удачный опыт работы с Aura.Di — лучше работать с ним дальше.
Статья еще раз убеждает следовать принципу: детали должны зависеть от абстракций. В нашем конкретном примере от интерфейса контейнера.
Серьезный выбор был между двумя микро-фреймворками: 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);
Серьезный выбор был между двумя микро-фреймворками: Slim и Zend.
Silex не рассматривался?
Вопрос по поводу контейнера. А на php-di не смотрели? И если смотрели, то почему его не взяли?
Sign up to leave a comment.
Опыт внедрения PSR стандартов в одном легаси проекте