Архитектурные вопросы в приложении (лог, настройки)

[Вурдалак]

WMix, тебе-то лучше знать о чём мы говорили, ога.

 

[WMix]

конечно понятно - "вы все дэбилы, а я, упырь, классный парень! ".

 

[HraKK]

мне лень сотый раз объяснять что я не против DI. Я против одного из неправильных аспектов его использования. Все, сотый раз повторять не буду. Если непонятно забейте, просто напросто. Тут тонкая грань, если ее коснетесь, то поймете, нет - значит оно вам не надо.

 

[HraKK]

Последний пример RequestObject который содержит входные параметры, его можно передавать по цепочке, а можно получить через DI. Первое правильно, второе убивать. Если не понятно - то извините и смотрите выше.

 

[WMix]

Вурдалак,

Место в топе подтверждает.

 

[Вурдалак]

HraKK, сам по себе RequestObject — нет, а какой-нибудь RequestProvider/RequestStack — вполне. Хотя это как раз неприятный пример stateful-сервиса. Например, интересно как иначе ты реализуешь sub-request в функции а-ля render() из Twig, который должен получить текущий объект request'а и создать на его основе новый и т.д.

 

[HraKK]

я не понимаю вопроса, я не знаю что такое sub request в функции render. Twig не юзал.

 

[Вурдалак]

HMVC ещё какое-то время называли такую хрень, подзапросы.
https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/HttpKernel/Fragment/FragmentHandler.php (см. зависимость RequestStack)
https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/HttpKernel/Fragment/InlineFragmentRenderer.php (см. InlineFragmentRenderer::createSubRequest)
— откуда тут взяться объекту $request? Т.е. всё замечательно, если у тебя нет понятия «подзапрос», new Request() будет где-нибудь в index.php, например, и всё. Если потребуется вызвать из шаблона подзапрос, то сервис, занимающийся этим, должен будет каким-то образом получить текущий $request, чтобы, например, проставить такие же заголовки.

Да и вообще, любой кейс, когда, например, происходит событие в каком-то контексте, где нет никакого $request, но при этом event listener может иметь зависимость от данных запроса: ниоткуда, кроме как из сервиса а-ля RequestProvider/RequestStack ты его не получишь.

Это пример stateful-сервиса без которого я не могу представить код.

Я бы убивал и расстреливал за такое.

Короче, HraKK, пощади, не убивай!

 

[WMix]

те. ради того чтоб доказать всем, что из твига можно вызывать экшин, ты затеял этот спор, правильно?
какойнить

<?=$this->action('бла/бла',array('id' => $this->id))?>

 

[Вурдалак]

WMix, плз, если ты не понимаешь о чем идет речь, то лучше оставь тему без комментария.

 

[fixxxer]

Вурдалак, мне лень читать код, но по идее же, при создании подзапроса можно было бы делать Subequest extends Request { getParent(), getRoot() }, не?

 

[Вурдалак]

fixxxer, так откуда ты parent возьмешь? И главное зачем делать subrequest отдельным классом? Тут говорят, что мол, request ни в каком виде через контейнер получать нельзя.

Короче, я утомился. Это диалог глухих со слепыми, каждый о своем.

 

[fixxxer]

Да я тут о другом вообще, не про DI. Понятно, что о чем ты говоришь - через контейнер можно, только будет проблема, что реквестов тоже может в один момент существовать несколько. Например, в случае event-based архитектуры. Или если треды появятся.

откуда ты parent возьмешь?

Ну вот же:

$subRequest = $this->createSubRequest($uri, $request);

 

[AmdY]

Вурдалак, твой пример как раз демонстрируем правоту HraKK, там идёт пробрасывания реквеста по цепочке, типичный middleware, потому через глобальный DI здесь не заинджектишь https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/HttpKernel/Fragment/InlineFragmentRenderer.php#L85

 

[Вурдалак]

fixxxer, вопрос именно в получении инстанса $request. Я не очень понимаю зачем нужен SubRequest, какую задачу он решает. Более того, это провоцирует на if ($request instanceof SubRequest).

 

[Вурдалак]

AmdY, там пробрасывается $request через метод, потому что это прямая задача этого сервиса (https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/HttpKernel/Fragment/FragmentRendererInterface.php), это часть интерфейса, это логично. А вот сам $request берется из сервиса $requestStack, который инжектится в конструктор: https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/HttpKernel/Fragment/FragmentHandler.php потому что по-другому получить $request нельзя.

 

[Вурдалак]

реквестов тоже может в один момент существовать несколько. Или если треды появятся.

Да, в этом проблема stateful, но я, честно говоря, не могу сходу сказать как тут нужно. Возможно а-ля scope из Symfony DIC.

 

[fixxxer]

fixxxer, вопрос именно в получении инстанса $request. Я не очень понимаю зачем нужен SubRequest, какую задачу он решает. Более того, это провоцирует на if ($request instanceof SubRequest).

Ну я вообще не очень понял, зачем может понадобиться именно корневой реквест параллельно с сабреквестом. Но если уж понадобился, то тогда логично решать в нормальном языке перегрузкой методов (а php - говно), ну либо спроектировать реквест с учетом субреквестов, а корневой бы при этом ссылался сам на себя.

 

[fixxxer]

Да, в этом проблема stateful, но я, честно говоря, не могу сходу сказать как тут нужно. Возможно а-ля scope из Symfony DIC.

А это вообще хороший тест на архитектуру фреймворка - взять и запустить без проблем внутри event loop, и чтобы ничего не перемешалось (проблемы с блокирующими вызовами не рассматриваю, только саму возможость). Симфони вполне себе может.

 

[stalxed]

Последний пример RequestObject который содержит входные параметры, его можно передавать по цепочке, а можно получить через DI. Первое правильно, второе убивать. Если не понятно - то извините и смотрите выше.

Я правильно понимаю, например, есть класс(из реальной задачи беру) ImportOrderStrategy, ему нужен ImportContextInterface, ImportLoggerInterface, EventDispatcherInterface.
1) Первый подход это(by HraKK version):

class ImportHelper
{
    private $context;
    private $logger;
    private $ed;
    public function construct(ImportContextInterface $context, ImportLoggerInterface $logger, EventDispatcherInterface $ed)
    {
        $this->context = $context;
        $this->logger= $logger;
        $this->ed = $ed;
    }
    public function getContext(){return $this>context;}
    public function getLogger(){return $this>logger;}
    public function getEd(){return $this>ed;}
}
class ImportOrderStrategy
{
    private $helper;
    public function construct(ImportHelper $helper)
    {
        $this->helper = helper;
    }
    public function someMethod(Order $order)
    {
        $this->helper->getContext()->addReplaced($order);
        $this->helper->getLogger()->log('one replaced');
        $this->helper->gerEd()->dispatch(OrderEvent::Replaced);
    }
}

2) Второй подход это(by HraKK version):

class ImportOrderStrategy
{
    private $context;
    private $logger;
    private $ed;
    public function construct(ImportContextInterface $context, ImportLoggerInterface $logger, EventDispatcherInterface $ed)
    {
        $this->context = $context;
        $this->logger= $logger;
        $this->ed = $ed;
    }

    public function someMethod(Order $order)
    {
        $this->context->addReplaced($order);
        $this->logger->log('one replaced');
        $this->ed->dispatch(OrderEvent::Replaced);
    }
}

Блин, пример из реального всё равно превратил в виртуальный, уменьшая количество кода.

Но я не вижу между этими подходами революционно огромной разницы.
ImportOrderStrategy даже в первом случае всё равно, пускай и косвенно, зависит от интерфейсов ImportContextInterface, ImportLoggerInterface, EventDispatcherInterface.
Сама зависимость никуда не пропадает.

Единственное отличие, при переходе со второго варианта на первый, ответственность за создание конкретных реализаций интерфейсов перекладывается с создателей ImportOrderStrategy на создателей ImportHelper.

Хотя... Плюс есть, ImportHelper можно применять повторно.