Zend_Registry: реальные примеры
Вы находите Zend_Registry полезный?
Для которых задач это должно использоваться? Для которого нет?
Глобальное состояние для переменных не является хорошей практикой. Основным объектам можно было ввести глобальное состояние через $front->setParam('paramName', $object), таким образом, какова цель Zend_Registry?.
3 ответа
Цитата PoEAA в шаблоне реестра :
Когда вы хотите найти объект, вы обычно начинаете с другого объекта, который связан с ним, и используете эту связь для перехода к нему. Таким образом, если вы хотите найти все заказы для клиента, вы начинаете с объекта customer и используете для него метод для получения заказов. Однако в некоторых случаях у вас не будет подходящего объекта для начала. Вы можете знать идентификационный номер клиента, но не иметь справки. В этом случае вам нужен какой-то метод поиска - поисковик, но остается вопрос: как добраться до искателя?
Основная причина, по которой я использую реестр (когда я его использую) потому что он создает легкодоступную область применения. С реестром мне не нужно захламлять объекты по всему миру; только сам Реестр глобален. Удобно искать все, что я добавил в реестр отовсюду, включая модель:
- Zend_Cache, Zend_Translate, важные пути приложений и т. Д.
Однако, как и с синглетонами, реестр часто не одобряется. Вот статья Брэндона Сэвиджа, в которой некоторые размышления о том, почему бы не использовать реестр . Основными аргументами против реестра являются
- , что он усложняет модульное тестирование
- , неопытные программисты могут вложить в него слишком много и не заботятся о правильном дизайне
. Те, кто голосует против реестра, обычно выступают за использование Внедрение зависимостей , хотя следует отметить, что вы также можете внедрить реестр после того, как получите его экземпляр.У вас нет инверсии управления , потому что использующий объект будет извлекать то, что ему нужно, из реестра. Тем не менее, использование реестра в качестве локатора сервисов - допустимый подход.
См. Эту статью Мартина Фаулера о ServiceLocator и внедрении зависимостей .
Как указано в комментариях к вашему вопросу, Zend_Registry не является строгим синглтоном. При необходимости вы можете создать несколько экземпляров в дополнение к глобальному экземпляру, который вы получаете с помощью Zend_Registry :: getInstance () . Таким образом, объекты могут иметь свой собственный реестр. Но при таком использовании реестра это просто прославленный объект ArrayObject.
Заключительное примечание: как и все шаблоны проектирования, используйте его, если применимо к вашей проблеме.
Я согласен с Паскалем МАРТИНОМ . Я только начал приучать себя к внедрению зависимостей. Но я не нашел способа внедрять объекты в контроллеры, поэтому недавно я использовал реестр для доступа к службе в контроллере. В текущем проекте я делаю следующее:
bootstrap:
// simple DI without an IoC container, and what have you
$dbAdapter = Zend_Db::factory( /* bla bla */ );
$mediaService = new Service_Media( new Repository_Media_Db( $dbAdapter ) );
$registry = Zend_Registry::getInstance();
$registry->mediaService = $mediaService;
... затем в контроллере:
public function init()
{
$this->_mediaService = Zend_Registry::get( 'mediaService' );
}
public function listAction()
{
// simplified
$this->view->media = $this->_mediaService->listAllUploadedVideos();
}
Надеюсь, это полезный пример для вас.
Когда вы используете $ front-> setParam , вы определяете параметр в Front Controller.
Но этот параметр недоступен в (или не должен использоваться) других уровнях приложения, таких как Модель.
Zend_Registry , как и любая другая глобальная переменная, доступна из любого места в вашем приложении, в том числе внутри модели.
Но использование реестра вместо группы глобальных переменных гарантирует, что у вас не будет много глобальных переменных повсюду: даже если использование реестра подразумевает какое-то глобальное состояние (что не очень хорошо, следует сказать) , лучше иметь все это в одном месте.
Вот несколько примеров из реальной жизни:
- Сохранить соединение с базой данных, которое установлено в bootreap, но используется в моделях.
- Глобально сохранить адаптер (или любой другой механизм) , который будет использоваться для перевода / локализации на всех уровнях вашего приложения - это делает сама Zend Framework.
В конце концов, могу ли я найти Zend_Registry полезным?
Что ж, когда дело доходит до некоторого глобального состояния, да, это полезно.
Но если его использования можно избежать, это может быть лучше: концептуально, лучше, если ваши классы не зависят от какого-либо глобального состояния: проще использовать повторно, легче тестировать, ...
Об этом, возможно, вы захотите взглянуть на то, что такое Dependency Injection .