Зачем использовать Dependency Injection в этом примере?

1

Рассмотрим следующий код:

class CategoryController
{
    private $model;

    public function __construct()
    {
        $this->model = new CategoryModel();
    }
}

Вы увидите, что контроллер зависит от модели. Я слышал, что делать это нежелательно, и вместо этого следует вводить модель.

Я спрашиваю, почему. В моем случае я создаю CategoryModel специально для CategoryController и я не вижу проблемы, оставляя его как внутри класса. Я имею в виду, я не могу ввести SomeOtherModel который не совместим в любом случае... или я могу?

Использование Dependency Injection вместо того, чтобы вводить его в контроллер, кажется пустой тратой кода.

Следовательно, есть ли причина использовать DI здесь?

  • 3
    Одной из причин использования DI является то, что вы не можете выполнить модульное тестирование CategoryController независимо, из-за зависимости от CategoryModel ... вы не можете издеваться над CategoryModel
Теги:
model-view-controller
dependency-injection

2 ответа

1

ответ

На самом деле в этом примере большой вопрос: что это такое?! Нет методов, которые просто держатель объекта, без возможности получить его !?

Да, я знаю, это просто пример, но это проблема, в этом примере вам не нужен DI, на самом деле вам даже не нужен класс вообще!

По словам @Mark Baker, без DI/IoC вы не можете легко протестировать, так как он плотно купируется. Если вы когда-нибудь прочитаете о тестировании, и в этом случае также Mockery

дополнительный

Использование Dependency Injection вместо того, чтобы вводить его в контроллер, кажется пустой тратой кода.

Когда в случаях, когда у вас нет чего-то, что делает DI для вас, легко разрешить объекты перейти от конструктора или сделать по умолчанию, в вашем примере будет что-то вроде: use CategoryModelInterface;

class CategoryController
{
    private $model;

    public function __construct(CategoryModelInterface $categoty = null)
    {
        $this->model = $category
            ? $category
            : new CategoryModel();
    }
}

Таким образом, вы не теряете много времени, и когда/если/возможно, вы сделаете некоторое тестирование или полностью измените модель для другого, на самом деле это возможно сделать.

0

Я не думаю, что вам понадобится здесь. Однако комментарий Марка Бейкера о тестировании действителен. Но вы можете обойти это, используя метод getter для модели. Затем этот метод можно издеваться над тестированием:

class CategoryController
{
    private $model;

    public function __construct()
    {
        ...
    }

    public function getModel() {
        if(!$this->model) {
            $this->model = new CategoryModel();
        }
        return $this->model;
    }
}
  • 0
    проблема с этим геттером в том, что у вас есть жестко закодированный CategoryModel. Как бы вы это проверили?
  • 1
    Я бы проверил это, издеваясь над геттером, и вернул бы то, что мне нужно, из этого - который в этом случае был бы поддельной CategoryModel.
Показать ещё 7 комментариев

Ещё вопросы

Сообщество Overcoder
Наверх
Меню