Подкиньте литературы или примеров по DI контейнерам.

Mex-Vision

Бессмертный
Iron Lord
Победитель в номинации 2022
Победитель в номинации 2021
Победитель в номинации 2020
Победитель в номинации 2019
Победитель в номинации 2017
Сообщения
833
Розыгрыши
0
Репутация
448
Реакции
545
Баллы
1 613
В общем поверхностно ознакомился с DI, хотелось бы узнать как лучше организовать проект и внедрить зависимости в контексте PHP. Возможно имеются какие-то хорошие примеры кода и т.п. Было бы интересно познать как с этим паттерном работают и с чем его едят.

Основная цель: Правильно работать с зависимостями и их организацией.
Цель: собрать небольшой проект с использованием Slim, PHP DI, Illuminate db, fenom и т.п.

Теоретических знаний в сети достаточно, а вот практических особо не нашел. Всё заканчивается на демонстрации того что и так есть в доках.

Первое недоумение возникло на моменте обращения к содержимому контейнера по ключам, что не дает возможности банально видеть публичные свойства и методы объекта. Как обычно решают данную проблему? Ведь крайне неудобно работать вслепую оО.
 
Последнее редактирование:

В общем есть вопросы, некому задать(
 
В общем поверхностно ознакомился с DI, хотелось бы узнать как лучше организовать проект и внедрить зависимости в контексте PHP. Возможно имеются какие-то хорошие примеры кода и т.п. Было бы интересно познать как с этим паттерном работают и с чем его едят.
DI является лишь частным случаем IoC. В качестве примера можете посмотреть реализацию в Symfony

Первое недоумение возникло на моменте обращения к содержимому контейнера по ключам
Покажите пример, так как по описанию выглядит подозрительно, будто Вы реализовали не DI, а Service Locator.
Предметная область не должна ничего знать о том, как Вы управляете зависимостями.
 
DI является лишь частным случаем IoC. В качестве примера можете посмотреть реализацию в Symfony


Покажите пример, так как по описанию выглядит подозрительно, будто Вы реализовали не DI, а Service Locator.
Предметная область не должна ничего знать о том, как Вы управляете зависимостями.
Ну к примеру вот кусок кода с документации php-di.

PHP:
$container = new Acclimate\Container\CompositeContainer();

// Add Symfony's container
$container->addContainer($acclimate->adaptContainer($symfonyContainer));

// Configure PHP-DI container
$builder = new \DI\ContainerBuilder();
$builder->wrapContainer($container);

// Add PHP-DI container
$phpdiContainer = $builder->build();
$container->addContainer($phpdiContainer);

// Good to go!
$foo = $container->get('foo');

Метод get не имеет представление какой тип данных возвращается, и поэтому ide не видит публичных методов, свойств и т.п. Приходится работать вслепую, либо при каждом использовании дописывать аннотации. Как обычно решают данную проблему?
 
Метод get не имеет представление какой тип данных возвращается, и поэтому ide не видит публичных методов, свойств и т.п.
Этот момент решается индивидуально для каждого из языков.
Для PHP можно юзать что-то типа
PHP:
/** @var FooClass */
$foo = $container->get('foo');

Или же с версии 7.4 для свойств классов можно указывать тип
PHP:
private FooClass $foo;

Конкретно в моем случае все немного проще, я могу указать какой тип возвращается из контейнера
Dr81yq8UKndZPm.jpg
 
Этот момент решается индивидуально для каждого из языков.
Для PHP можно юзать что-то типа
PHP:
/** @var FooClass */
$foo = $container->get('foo');

Или же с версии 7.4 для свойств классов можно указывать тип
PHP:
private FooClass $foo;

Конкретно в моем случае все немного проще, я могу указать какой тип возвращается из контейнера
Посмотреть вложение 42470
Ну вот мне было интересно как с этим работают в контексте php. Каждый раз при использовании писать аннотацию не сильно прикольно. Хорошим ли тоном будет создать фасад, например App.php, в нем сделать статик методы которые будут брать из контейнера компоненты, например:

PHP:
class App extends Facade
{
    public static function getFoo(): FooInterface
    {
        return static::$app->get('foo');
    }
}

$foo = App::getFoo();
И обращаться всегда через фасад, метод которого знает тип возвращаемого значения.
 
Каждый раз при использовании писать аннотацию не сильно прикольно.
В реальном проекте не придется слишком много дергать get()
Для примера в Symfony контейнер конфигурируется через отдельный конфиг, не надо дергать контейнер напрямую:
krD4lvNTGLw43r.jpg

И обращаться всегда через фасад, метод которого знает тип возвращаемого значения.
И в итоге превратится это в подобие глобального Service Locator'а, почти как в том же Yii. Лично я бы не рекомендовал.

Попробуйте просто использовать Symfony для своих проектов, Вам должно понравиться.
 
Попробуйте просто использовать Symfony для своих проектов, Вам должно понравиться.
Присматривался и к Symfony и к Laravel. Ну хоть убейте, не нравится мне структура приложения, разбросанные шаблоны, стили в public, шаблоны в другой директории, тонна конфигурации, веб сервер направлять в папку, и т.п. Хотелось собрать что-то простое, залил - работает. А не конфигурировать каждый раз веб сервер, за ним еще около десятка конфигов самого сайта и т.п. Понимаю что для большого проекта фреймворк это необходимость, но для меня прям хз.
 
Угу, как раз PHP-DI и используется, потому выбор на него и пал)
Нет там же написано
Slim supports containers that implement like .
 
Каждый раз при использовании писать аннотацию не сильно прикольно.
Имхо, не вижу нечего плохого в описании сервиса)

В симфони уже автовайр есть давно как-бы...
У тебя один сервис ямл файл.
И твои сервисы будут работать, если правильно описывать их)
1652263654564.png
1652263757743.png
 
deleted, нечитал ответы, но php-di норм. Правда я не стал парится, мне удобнее было написать класс Container который при __get() создает свойство с экземпляром класса, а где нужно я уже делаю $this->my_class->my_method(); , это может не самая удачная реализация, но мне удобно
 
m1ckey, ну как бы нормальные люди так и делают
1652278047960.png
 
Назад
Сверху Снизу