Внедрение зависимостей необязательных пользовательских компонентов - PullRequest
Новая
       5

Внедрение зависимостей необязательных пользовательских компонентов

1 голос
/ 24 ноября 2011

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

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

Вместо того, чтобы создавать объект конфигурации ядра в конкретном контроллере, я внедряю объект конфигурации ядра в контроллер, поскольку это облегчит тестирование (и будет следовать принципу внедрения зависимостей).

Это все хорошо и имеет смысл, но что происходит с объектом конфигурации приложения? Пользователь мог бы использовать платформу, и НИКОГДА не нуждаться в объекте / файле конфигурации, специфичном для приложения, и поэтому внедрение объекта конфигурации, специфичного для приложения, для каждого контроллера кажется неэффективным и бесполезным расходом ресурсов

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

Пожалуйста, имейте в виду, что я очень плохо знаком с идеей внедрения зависимостей и TDD, поэтому я предполагаю, что есть очень тривиальное решение вопроса выше, но я еще не наткнулся на него из всех статей Я прочел.

Я думал, что нашел ответ в этой http://misko.hevery.com/2008/08/21/where-have-all-the-singletons-gone/ Misko Hevery статье, но я думаю, что фабрики не решают проблему необязательных пользовательских компонентов.

1 Ответ

0 голосов
/ 12 ноября 2012

Если я правильно понимаю, вас беспокоит факт инъекции предметов, которые могут не в конечном итоге использоваться.

Эту проблему можно решить с помощью lazy-инъекция , которая является инъекцией пустого прокси-объекта , который будет загружать «настоящий» объект только тогда, когда он используется.

PHP-DI поддерживает его, например: 

class Class1 {
    /**
     * @Inject(lazy=true)
     * @var Class2
     */
     private $class2;
...