Правильно ли я использую PHP-DI?

Question

[Miku Hatsune]

Сам DI - php-di.org
Вроде бы я понял суть паттерна, но не понял как его применять...

Например вот такой код (Упрощённый и собранный в кучу для примера):

<?php
require_once '../vendor/autoload.php';

use DI\ContainerBuilder;

$di = ContainerBuilder::buildDevContainer();

$di->set('db', new class {
	public function getRow ()
	{
		return [
			'name'   => 'MyName',
			'family' => 'MyFamily',
			'age'    => '17'
		];
	}
});

abstract class BaseController
{
	protected $di;

	public function __construct ($di)
	{
		$this->di = $di;
	}

	abstract function indexAction ();
}

class Controller extends BaseController
{
	public function indexAction ()
	{
		$row = $this->di->get('db')->getRow();

		// Пример всё таки, не прикручивать же для него шаблонизатор
		echo 'Name: ',$row['name'],'<br> Family: ',$row['family'],'<br> Age: ',$row['age'];
	}
}

$controller = new Controller($di);
$controller->indexAction();

Правилен ли подход в целом? И ещё, меня смущает вот это:

$row = $this->di->get('db')->getRow();

Хочется попроще как то так:

$row = $this->db->getRow();

Как это сделать с PHP-DI? И возможно ли вообще?

Answer 1

[Сергей Протько]

нет, вы не правильно уловили идею. Передавать весь контейнер в качестве зависимости это нарушение этого самого паттерна и принципа инверсии зависимостей. Так можно делать только в случае циклических зависимостей либо же просто как альтернатива ленивой инициализации сервисов (хотя альтернатива так себе, а циклических зависимостей надо избегать).

1) читаем про принцип инверсии зависимостей
2) читаем про внедрение зависимостей
3) если уж используете безымянные классы то они должны имплементить какой-то интерфейс или же экстендиться от какого-то класса.

Вместо того что вы хотите должно быть:

class Foo {
     private $db;

     public function __construct(Connection $connection) {
           $this->db = $connection;
     }

     public function makeFoo() {
          return $this->db->getRows(); // как вы и хотели
     }
}

// а это уже дергаем в конструкторе
$foo = $di->get(Foo::class);
$foo->makeFoo();

то есть в контроллерах мы дожны дернуть сервис который вернет нам готовые данные.

Comments

[Miku Hatsune]

> если уж используете безымянные классы то они должны имплементить какой-то интерфейс

Это я так, к примеру. В реальных условиях так не делаюю

Как я понял из вашего примера, каждый нужный мне сервис - отдельное свойство класса. Которое через конструктор регистрируется? И суть DI как раз зарегистрировать их вместо меня?

или опять не так понял?...

[Сергей Протько]

Miku Hatsune:

"внедрение зависимостей". Даже из перевода должно быть понятно. Храните вы в свойствах или как угодно - это не суть. Суть в том что зависимость передаются явно а не создаются на местах с использованием глобальных конфигов и т.д. На этом зона ответственности контейнера зависимостей заканчивается, он просто ресолвит граф зависимостей.

[Сергей Протько]

Miku Hatsune: есть еще "принцип инверсии зависимостей", его часто путают с "внедрением зависимостей". Почитайте на досуге.

[Miku Hatsune]

Пересмотрел ещё на пару десятков раз пример, понял похоже... Сперва я регаю в DI сервисы. А уже потом через этот же DI создаю объект контроллера.

Но я тогда немного не понял как быть с множеством сервисов... "Объявлять" только те, что нужны?

Например мне нужно не только доступ к базе данных, но и к классу request

<?php
class Controller 
{
    private $db;
    private $request;

    public function __construct (Request $request, Database $db)
    {
        $this->request = $request;
        $this->Database = $db;
    }

    public function indexAction ()
    {
        // Использую $this->db
        // Использую $this->request
    }
}

$controller = $di->get(Controller::class);
$controller->indexAction();

Правильно?

[Miku Hatsune]

$this->Database = $db; ошибочка вышла. $this->db = $db;

[Сергей Протько]

Miku Hatsune: нет, Request это не зависимость конструктора, это аргумент экшена. Посмотрите как это все реализовано в Laravel5, пробуйте сделать так же. Там и сервисы для экшена через дабл диспатч можно подтягивать.

Answer 2

[xfg]

Неправильно. Внедряйте зависимости, а не контейнер. Вы нарушаете Закон Деметры. Будут те же самые проблемы при классическом подходе к юнит-тестированию, как если бы вы вообще ничего не внедряли и инстанциировали все зависимости прямо в классе.

Answer 3

[dmitriy]

в Falcon успешно используется такой подход docs.phalconphp.ru/ru/latest/reference/di.html

Comments

[Miku Hatsune]

Я знаю их поход, я сам использую phalcon. Или я чего не понимаю просто судя по комментам выше там неправильный DI...

[dmitriy]

выходит так

[Miku Hatsune]

diamond: там DI в основном вредряется в конструкторе