Почему мне не хочется использовать Yii?

Sam Dark

Новичок
Не, есть ещё и DI-контейнер, который содержит конфиг и используется тем компонентом, что инжектит в другие компоненты. У нас инжектить умеет приложение (именно оно создаёт компоненты), и конфигом выступает его же свойство components.

Из Yii::$app обычно берётся лишь компонент по умолчанию, но его можно и проинжектить через конфиг. Так гибче, тестировать легче и API не как звездолёт.
 

MiksIr

miksir@home:~$
> У нас инжектить умеет приложение
Про Yii2 речь? В Yii1 как-то не видел я такого... ну кроме behavior разве что, может просто плохо понимаю о чем речь.
 

Redjik

Джедай-мастер
Sam Dark

вообще то есть =)
1) http://fabien.potencier.org/article/11/what-is-dependency-injection
2)

это так, что когда ты обращаешься к Yii::app()->db то обращаешься к базе, а вот к какому типу(mysql,pg,mssql,sqlite), инжектится через getDriver в схеме вроде
можно называть по-разному - сути не меняет, так что не вижу причин для скепсиса.
 

MiksIr

miksir@home:~$
это так, что когда ты обращаешься к Yii::app()->db то обращаешься к базе, а вот к какому типу(mysql,pg,mssql,sqlite), инжектится через getDriver в схеме вроде
можно называть по-разному - сути не меняет, так что не вижу причин для скепсиса.
В этом случае мы можем говорить, что Сервис локатор использует DI. И только он. И то если там нет никаких созданий объектов а только набор set/get.
 

Redjik

Джедай-мастер
В этом случае мы можем говорить, что Сервис локатор использует DI. И только он. И то если там нет никаких созданий объектов а только набор set/get.
Я не пойму вообще о чем спор то?
Просмотри видео, прочитай статьи Фабиена, можешь даже фаулера глянуть - 2003 год вроде статья была.
Все говорят, что то, о чем ты говоришь - DIC, хочешь называй Service Locator. Сути то не меняет.
 

Sam Dark

Новичок
Redjik
У Fabien Potencier объяснение, конечно, не такое хорошее как у Anthony Ferrara. Больше путает, чем объясняет :) Проблема в том, что смотрит и осознаёт такие видюшки очень мало человек. Ну и вторая проблема в том, что там не объяснено, что контейнер может быть не только контейнером, но и, например, экземпляром $app.

> У нас инжектить умеет приложение
Про Yii2 речь? В Yii1 как-то не видел я такого... ну кроме behavior разве что, может просто плохо понимаю о чем речь.
Речь и про 1.1 тоже.

В этом случае мы можем говорить, что Сервис локатор использует DI. И только он. И то если там нет никаких созданий объектов а только набор set/get.
Что за крайности? Если какие-то части какого-то класса не используют DI это не значит, что в фреймворке нет DI вообще. Думаю, сложно найти ОО-код, в котором нет ни одного сеттера или конструктора, в который передаётся объект для последующего его использования.
 

MiksIr

miksir@home:~$
Я не пойму вообще о чем спор то?
Просмотри видео, прочитай статьи Фабиена, можешь даже фаулера глянуть - 2003 год вроде статья была.
Все говорят, что то, о чем ты говоришь - DIC, хочешь называй Service Locator. Сути то не меняет.
Ну вот я по фаулеру и говорю.
http://www.martinfowler.com/articles/injection.html
 

MiksIr

miksir@home:~$
Что за крайности? Если какие-то части какого-то класса не используют DI это не значит, что в фреймворке нет DI вообще. Думаю, сложно найти ОО-код, в котором нет ни одного сеттера или конструктора, в который передаётся объект для последующего его использования.
Крайностей нет, есть определения.
Говоря о инжекции зависимостей говорим, что это основной принцип нашего кода.
Если у нас половина зависимостей инжектируется в класс, а половина - прописана в классе - это уже не DI.
 

MiksIr

miksir@home:~$
PHP:
class Container {
  public static function getInstance() {
      // синглтон
  }
  public function getComponent() {
     return new Component();
  }
}

class Component {

   public function someMethod() {
        Container::getInstance()->getComponent();
   }

}
Где тут DI?
 

Sam Dark

Новичок
Это к чему ошмёток кода? Пример контейнера из Symfony?

Говоря о инжекции зависимостей говорим, что это основной принцип нашего кода.
Если у нас половина зависимостей инжектируется в класс, а половина - прописана в классе - это уже не DI.
Определения такого не слышал ни разу. Звучит как раз как крайность и паттернизм:

— Есть крутой паттерн DI!
— Давайте его применим везде!!!
— А вот тут без него проще и подменять компонент никто в этом месте не должен.
— Нее, надо везде! Если где-то забудем — будет не DI.
 

MiksIr

miksir@home:~$
Да, кажетя я понимаю в чем проблема. Интересно, кто стал использовать термин DI Container? Сервис-локатор все же более правильное и самое главное - менее путающее название. Как минимум потому, что не путает с DI.
DI и DI Container - это вещи совершенно не связанные.
DI Container в чистом виде - это сервис локатор, и так его стоит называть. Это ни разу не DI вообще, ибо наши классы зависят от сервис-локатора.
О DI Container можно говорить только совместно в DI. Т.е. у нас есть принцип инжектирования зависимостей. И есть контейнер, который упрощает знает кому и сколько инжектировать. Это ни разу не сервис-локатор.
 

Gas

может по одной?
Все говорят, что то, о чем ты говоришь - DIC, хочешь называй Service Locator. Сути то не меняет.
это всё таки разные вещи.
IoC - это общий принцип, который включает в себя push(DiC) и pull(Service Locator) подходы.
DiC используется для инстанцирования объектов и передачи их явно в конструкторы/методы, при этом в интерфейсе объяекта явно видны его зависимости, и не нужно рыться в коде для этого, как это происходит в локатором, который уже внутри метода тянет то что нужно.
Тестированию локатор не мешает, конечно он лучше чем явный new.

Это так, как я это всё понимаю. Но понимаю что с локатором проще код писать и тестированию он в принципе не сильно мешает, если позволяет динамически подменить объект в тестах.
На средне-мелких проектах имхо и локатора достаточно, а большие составляют не большой процент.

— Нее, надо везде! Если где-то забудем — будет не DI.
угу, иногда смотришь на Symfony2 и Zend2, и думаешь - ну нафига столько понавпихивали :)
 

Sam Dark

Новичок
Фиг его знает, кто стал использовать, но запутало это народ неслабо... Предлагаю выкинуть все термины и пообщаться кодом :)

Отчасти из за вот таких недопониманий и вкладывания разного смысла в паттерны мы не акцентируем в фреймворке внимания на то, какие именно паттерны где используются и в API отсутствуют классы и методы аля ServiceLocator::getMyCoolProxyAdapterInjector(). Вместо них Yii::app()->myComponent.
 

Sam Dark

Новичок
Gas, на больших с локатором тоже всё норм. Главное им не увлекаться сверх меры.
 

MiksIr

miksir@home:~$
Это к чему ошмёток кода? Пример контейнера из Symfony?


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

— Есть крутой паттерн DI!
— Давайте его применим везде!!!
— А вот тут без него проще и подменять компонент никто в этом месте не должен.
— Нее, надо везде! Если где-то забудем — будет не DI.
Возможно. Для меня это так - если мы инжектируем зависимость - мы инжектируем зависимость. DI нужен не только для того, что бы легко подменить. Он нужен еще для того, что бы показать - а от чего же зависит ваш класс, т.е. по сути документация. Смешивая DI и прописанные зависимости вы делаете еще хуже - с одной стороны мы рассказываем о зависимостях, с другой стороны - прячем еще кучу зависимостей.
С таким подходом можно договориться и о "а зачем нам тут делать какой-то класс статический или создавать объект, если для моих целей функцию напишу и нормально".
 
  • Like
Реакции: AmdY

MiksIr

miksir@home:~$
Фиг его знает, кто стал использовать, но запутало это народ неслабо... Предлагаю выкинуть все термины и пообщаться кодом :)

Отчасти из за вот таких недопониманий и вкладывания разного смысла в паттерны мы не акцентируем в фреймворке внимания на то, какие именно паттерны где используются и в API отсутствуют классы и методы аля ServiceLocator::getMyCoolProxyAdapterInjector(). Вместо них Yii::app()->myComponent.
Нету в Yii инжектирования зависимости. Сервис локатор есть, можете DI контейнер его назвать, но все же Фаулер его зовет сервис-локатором.
Если бы вы в application при создании компонетов хотя бы инжектировали этот локатор, и в компонентах использовали эту инжектированную сущность.... ну это все-равно фигня была, хоть можно было бы DI назвать.
Что бы Yii был DI - ваш application должен, при создании компоненты, инжектировать в нее другие компоненты - и только те, которые нужны. Вот что я понимаю под фреймворком использующем DI. На правоте не настаиваю, но пока не вижу, где неправ. Покажите.
 

MiksIr

miksir@home:~$
это всё таки разные вещи.
IoC - это общий принцип, который включает в себя push(DiC) и pull(Service Locator) подходы.
DiC используется для инстанцирования объектов и передачи их явно в конструкторы/методы, при этом в интерфейсе объяекта явно видны его зависимости, и не нужно рыться в коде для этого, как это происходит в локатором, который уже внутри метода тянет то что нужно.
Тестированию локатор не мешает, конечно он лучше чем явный new.

Это так, как я это всё понимаю. Но понимаю что с локатором проще код писать и тестированию он в принципе не сильно мешает, если позволяет динамически подменить объект в тестах.
На средне-мелких проектах имхо и локатора достаточно, а большие составляют не большой процент.
В общем вот тут согласен со всем.
Вот еще нашел забавную ссылочку... даже припоминаю, что раньше ее видел...
http://www.loosecouplings.com/2011/01/dependency-injection-using-di-container.html
 

Sam Dark

Новичок
Так оно и происходит. Application берёт конфиг, секцию "components". В ней, например, прописано:

PHP:
'log' => array(
  'class' => 'yii\logging\Router',
  'targets' => array(
    'file' => array(
      'class' => 'yii\logging\FileTarget',
      'levels' => array('error', 'warning'),
    ),
  ),
),
При обращении к компоненту log приложение создаёт указанный класс (он нигде не хардкоднут и перекрывается через конфиг), пробегается по остальному конфигу и через сеттеры (или прямо в свойства) инжектит значения в только что созданный класс. Если нужно, конфижит ещё и зависимости, чтобы они создавались с указанным конфигом.
 
Сверху