PHP Dependncy Injection & Complexity

Question

Я много исследовал теорию инъекций зависимостей, и это имеет большое значение, за исключением того, что, по-видимому, в некоторых сценариях возникает сложность/раздувание.

Во-первых, предполагается, что экземпляр контейнера DI никогда не передается ни одному объекту. Плохая практика и все такое ...

Например: рассмотрите класс «пользователь», который относится ко всем другим бизнес-объектам, созданным в системе, для/для определенного пользователя.

Если экземпляр пользователя должен быть удален, все связанные объекты (например, записи, файлы, изображения и т. Д.) Также необходимо удалить. Означает ли это, что экземпляр каждой зависимости должен быть введен в пользовательский экземпляр, чтобы разрешить поиск и удаление всех связанных объектов? то есть экземпляр ImageMapper (или ImageMapperFactory) должен быть передан, чтобы удалить все изображения, созданные/загруженные удаляемым пользователем экземпляром пользователя?

Если нет, является ли такой сценарий хорошим примером того, где должен использоваться локатор службы?

Я нахожу его повторяющимся снова и снова в статьях & учебников, которые программист должен избегать использования «нового» в любом классе, таком как чума. Однако действительно ли это возможно для экземпляров контроллеров, которым может потребоваться создать множество представлений или тому подобное?

Будет рассмотрен конкретный пример соблюдения SOLID-мантры, по крайней мере, в отношении DI ... Тот, который дает понять, как можно либо заполнить экземпляры ВСЕХ требуемых зависимостей в классе контроллера, либо как будут ли найдены или созданы лучшие экземпляры таких зависимостей?

Answer 1

Я не знаю PHP, но я попытаюсь объяснить некоторые вещи, поэтому ваш вопрос не будет забыт, так голый со мной. ;-)

Я считаю, что инъекции зависимость лучше всего работает путем разделения приложения в слоях:

• Presentation Layer - Some интерфейс (пользовательский), который обеспечивает взаимодействие с приложением.
• Business Logic/Service Layer - фактическое поведение вашего приложения.
• Стойкость/уровень доступа к данным - уровень, который хранит/считывает данные из внутреннего блока (попробуйте найти шаблон репозитория).

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

Когда ваша логика приложения заявляет, что изображения пользователя должны быть удалены при удалении пользователя, вы захотите это в среднем слое (бизнес-логика). Уровень бизнес-логики вызывает уровень доступа к данным для удаления объектов.

Давайте продемонстрируем использование Python (надеюсь, вы сможете это прочитать).

# Define a class that manages users. 
class UserService: 
    # A constructor accepting dependent DAL instances. 
    def __init__(self, user_repo, image_repo): 
     self.user_repo = user_repo 
     self.image_repo = image_repo 

    def delete(self, user): 
     self.user_repo.delete(user) 
     self.image_repo.delete(user.profile_picture) 

аргументов РЬИХ, которые идут в конструкторе, являются экземплярами классов репозитория, это зависимость инъекции (инъекции конструктора).

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