Различия сцепления Laravel DI

Question

Различия сцепления Laravel DI

Какая разница в соединении классов, если вы используете эти 3 типа использования:

Случай 1

use UserRepository

...

UserRepository::getUser();

Дело 2

App::make('UserRepository')->getUser();

Дело 3

public function __construct(UserRepository $userRepository)
{
$this->userRepository = $userRepository;
}
...
$this->userRepository->getUser();

Есть ли причина отдавать предпочтение одному другому?

РЕДАКТИРОВАТЬ

Я чувствую, что вариант конструктора — лучший путь, но я нахожусь под вопросом, когда мне нужно включить 3 контроллера и 3 репозитория в контроллере, который затем очень быстро увеличивается до 6 параметров в конструкторе.

РЕДАКТИРОВАТЬ — Дело 4

Как насчет того, когда вы используете фасад вместо?

РЕДАКТИРОВАТЬ — Дело 5

Как насчет того, когда вы указываете это как \UserRepository?

2

coupling dependency-injection laravel php

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Прежде всего, идея репозитория состоит в том, чтобы иметь интерфейс (UserRepositoryInterface) и классы, которые его реализуют (MySQLUserRepository, RedisUserRepository). Это дает вам быстрый способ изменить хранилище пользователей через ваш DI-контейнер, вызвав интерфейс:

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

И изменить его на любую реализацию в контейнере DI.

Допустим, у вас есть контроллер с 10 действиями.

Случай 1 Это не путь ООП, потому что вызов вообще не проходит через контейнер DI.

Дело 2 на самом деле все в порядке, но вам придется вызывать фасад приложения в каждом действии. Это не очень красиво.

Дело 3 дает вам только одно место для создания / изменения / настройки класса.

Например. вам нужно сделать что-то вроде:

public function __construct(UserRepository $userRepository)
{
$this->userRepository = $userRepository;
$this->userRepository->excludeAdmins();
}

Многие репозитории в конструкторе на самом деле в порядке, однако, если код заполнит вас полностью, вы можете извлечь его в класс Service.

ОБНОВИТЬ
Под классом обслуживания я подразумеваю класс, который ничего не расширяет и содержит бизнес-логику.

Дальнейшее чтение: https://m.dotdev.co/design-pattern-service-layer-with-laravel-5-740ff0a7b65f

Дело 4. Фасады, на мой взгляд, подходят для чего-то более глобального. Почему вы хотите заполнить каждый репозиторий фасадом? Слишком много времени.

Дело 5. Не получил вопрос. Вы имеете в виду поместить его в корневое пространство имен? Что это меняет?

1