# AlkatraZ (17.11.2016 / 13:50)
И этому есть серьезные аргументы со ссылками на авторитетные первоисточники (на английском).
Да ну их те авторитетные источники.
Мне много чего не нравится из того что сейчас пытаются сделать правильным и мейнстримным.
Тот же PSR-7, который ничего полезного из реальной жизни не описывает зато заставляет меня иметь имутабельные запрос/ответ.
Накой черт оно мне нужно если я РНР не собираюсь использовать не для чего иного кроме как stateless приложений?
Мидлухи ихние туда же, зачем там в аргументах передается ответ? Чтоб его там модифицировать? Так он же валюэ-обжект и все равно при изменении любого свойства он клонируется.
Не нравится мне это всё.
Говоря немного отвлеченно, в mobiCMS я давно экспериментировал с DI и применял это на практике к конкретным задачам.
Если глянете сюды:
https://github.com/zendframewo ... e.php
И сюды:
https://github.com/Gazenwagen/ ... r.php
тут применяется классический DI с анализом классов, автоматикой и автоподстановкой всех зависимостей.
Да. с одной стороны все хорошо и круто: запросил у контейнера класс - бац, получи его, со всеми зависимостями и т.п.
Но не все так просто: автозависимости накладывают очень жосские требования по программированию. Кажущуяся простота в итоге оказывается реальным гемороем: в DI чересчур много магии и неоднозначностей, зачастую очень трудно проследить ОТКУДА и как берется конкретный объект. Что в свою очередь вызывает геморой с отладкой и поиском багов.
А тогда вернемся к вопросу: на..я DI?
Чтоб облегчить работу?
Ну и где там облегчение, если реальный геморой?
Посему, начиная с 2015 года, большинство серьезных разработчиков фреймворков начали отходить от магии в DI и склоняться к реализации Service Locator в виде Factory-Driven Dependency Injection Container
После, как на практике я "прощупал" данный подход, сам стал его преверженцем: несмотря на необходимость писать множество фабрик, на самом деле поведение полностью предсказуемо, все кликабельно, легко рефакторится и более того. в фабрике можно реализовать любое поведение. что никак невозможно реализовать в автоматических вариантах DI,
Примеры Factory-Driven Dependency Injection Container:
zend-servicemanager (container-interop совместимый начиная с 3-й версии)
Aura.Di (container-interop совместимый начиная с 3-й версии)
Pimple
# L!MP (17.11.2016 / 14:00)
Да ну их те авторитетные источники.
Весь прикол в том, что статей по этому поводу почти не прочитаешь...
Мануалы - устаревшие. пейсатели пишут на несколько лет отставши.
Главный интерес - в каментах к исусам на гитхабе серьезных проектов. Потом если будет время, я постараюсь найти ссылки и скинуть. Там действительно, как будто сам исследуешь джунгли с компаньоном, более того, можно спросить у (гру) первоисточника, почему так?
Этих "первоисточников" часто "прет", они пишут код, а (как обычно) документация к нему сильно отстает гг.
AlkatraZ, Zend сами рекомендуют отказываться от DI в пользу обычного ServiceLocator
в DI чересчур много магии и неоднозначностей, зачастую очень трудно проследить ОТКУДА и как берется конкретный объект
Как ты там между десятком классов используемых в движке смог запутаться одному богу известно, гг.
Ну и в контейнере магии вообще нет, а если смущает, то отключай автовайринг и все зависимости указывай ручками.
Ну и да, финальный аккорд вообще смешной.
То что в зенд есть класс сервис локатор не значит что "большинство серьезных разработчиков фреймворков начали отходить от магии в DI".
# Delphinum (17.11.2016 / 14:12)
AlkatraZ, Zend сами рекомендуют отказываться от DI в пользу обычного ServiceLocator
именно.
Потому я же и пошел по этому пути. а когда освоил и привыкт (потребовалось время), оказалось. что намного проще, предсказуемее и понятнее.
L!MP, весь PSR это всего лишь стандарт. Создавался этот стандарт после конференции головных разработчиков различных фреймворков и PHP комьюнити, на которой пришли к выводу, что нужно стандартизировать низкоуровневые, прикладные решения в виде интерфейсов, для того, чтобы различные их реализации (на пример реализации от Zend, Symfony, Yii и т.д.) были взаимозаменяемыми. Это хорошее решение и правильный путь развития для PHP, но часто конкретный PSR (тот же 7, где про HTTP) довольно спорный.
# L!MP (17.11.2016 / 14:13)
То что в зенд есть класс сервис локатор не значит что "большинство серьезных разработчиков фреймворков начали отходить от магии в DI".
А я зенд просто для примера (мы его применяем) привел.
Читани каменты к Сисмфонии, глянь ауру и т.п. развивающиеся фреймворки, не попсу.
# Delphinum (17.11.2016 / 14:15)
весь PSR это всего лишь стандарт
Более того, это не стандарт. а рекомендации.
Ты можешь их соблюдать, а можешь и нет. так сказать "визитная карточка" в клуб.
# L!MP (17.11.2016 / 14:13)
То что в зенд есть класс сервис локатор не значит что "большинство серьезных разработчиков фреймворков начали отходить от магии в DI".
Тут дело не столько в Zend, они лишь привели несколько очень серьезных доводов в пользу отхода от DI, на основании которых и предложили отказываться. Но отмечу, что они не просто предлагают - откажитесь от DI и все тут - они оговаривают условия, при которых DI уступает классическому ServiceLocator, но эти условия во многих проектах соблюдаются далеко не всегда, потому в них применение DI вполне оправданно.
