Недавно я начал использовать Pimple (вместе с Silex). В зависимости от того, как используется Pimple, это может быть либо локатор службы, либо контейнер внедрения зависимости.
Мне известны причины, по которым следует избегать шаблона Service Locator. Тем не менее, одна вещь, которая, кажется, преследует меня, — это момент, когда создается экземпляр зависимости.
В случае внедрения зависимости, экземпляры необходимых классов создаются и передаются в конструктор:
class Foo{
public $depend1;
public $depend2;
public function __construct($depend1, $depend2) {
$this->depend1=$depend1;
$this->depend2=$depend2;
}
public function task1() {
return $this->depend1->run();
}
public function task2() {
return $this->depend2->run();
}
}
В случае, если мы передадим сам контейнер конструктору класса, экземпляры зависимостей не нужно создавать, пока они не понадобятся.
class Foo{
public $app;
public function __construct(\Silex\Application $app) {
$this->app=$app;
}
public function task1() {
return $app['depend1']->run();
}
public function task2() {
return $app['depend2']->run();
}
}
В результате, даже если мы собираемся вызвать только один из двух методов класса Foo, в первом примере все равно будут созданы оба экземпляра зависимости. Этот код очень простой пример, но я ожидаю, что проблема будет расти в случае более сложных классов с большим количеством структур зависимостей. Я заметил, что некоторые другие контейнеры для инъекций зависимости используют прокси-классы, но не смогли найти ничего для этой библиотеки. Есть ли лучшая альтернатива ленивой загрузке зависимостей с помощью Pimple?
В большинстве случаев это не проблема. Если инициализация ваших зависимостей становится реальной проблемой производительности, вам следует либо разбить службу на две отдельные службы, либо создать прокси-сервер, который lazyload загружает зависимость при первом вызове.
Существует библиотека для PHP, которая обеспечивает автоматическую генерацию прокси, которая называется ProxyManager. Не зная ваших требований, я думаю, что это, вероятно, излишне для вас. Не беспокойтесь об этом, пока не будете уверены, что существует реальное узкое место в производительности, которое вы можете решить таким образом.
Других решений пока нет …