Zend_Registry - можно ли проще?

sverel

Новичок
Решил я в своём велосипеде избавится от засорения глобальной области видимости. Прикрутил Zend_Registry и начал везде всё заменять. Но сразу же возникли сомнения: там где раньше было одно примитивное действие, теперь начали появляться по 2-4 строки кода. Судите сами:

Было:
PHP:
// Пример первый (конкатинация):
$GLOBALS['title'] .= ' - новости';


// Пример второй (проверка на "не пусто"):
if ( ! empty($GLOBALS['currentSection']['metaKeyWords'])) {
    // ....
}


А вот так стало после прикрутки Zend_Registry:
PHP:
// Пример первый (конкатинация):
$tmp = Zend_Registry::get('title');
$tmp .= ' - новости';
Zend_Registry::set('title', $tmp);


// Пример второй (проверка на "не пусто"):
if (Zend_Registry::isRegistered('currentSection')) { // Эта переменная может не существовать
    $currentSection = Zend_Registry::get('currentSection');
}
if ( ! empty($currentSection['metaKeyWords'])) {
   // ...
}
И я задумался: зачем использовать класс, который, не предоставляет никакого нового ф-ционала в отличае от phpExcel или Zend_Form. Это всего лиш ещё одно хранилище для переменных. В результате родилась идея вместо класса создать всего одну глобальную переменную:

PHP:
$GLOBALS['registry'] = array();
Это лишь немного усложнит первоначальный примитивный код:
PHP:
$GLOBALS['registry']['title'] .= ' - новости';
В итоге мы имеем следующие преимущества:
1. Не надо засорять систему лишними классами, которые не предоставляют новый ф-ционал.
2. Не надо документировать->переводить->изучать новое API.
3. Используются стандартные нативные инструменты и языковые конструкции php.
4. Создание одной переменной вряд ли можно назвать "ЗАСОРЕНИЕМ глобальной области видимости".
5. Имеем полный контроль над реестром. В любой момент можно просмотреть всё его содержимое или очистить его.


Как Вам такая идея?
Или быть может я не умею использовать Zend_Registry ?
 

Вурдалак

Продвинутый новичок
Непонятно зачем тебе эти переменные делать глобальными. Явно или через этот Zend_Registry.
 

sverel

Новичок
Title и мета-тэги изначально рождаются дефолтными. Потом по ходу хлебных крошек переопределяются разделами->подразделами->элементами раздела.

Да и вопрос как бы не об архитектуре моего велика. Кроме титлов и метатегов есть ещё много других переменных, которые раньше были в глобальной области видимости.
Я бы даже сказал так: есть метод Zend_Registry::set(), но нет метода ::concatinate(); ::increment(); и т.п... и изобретать их конечно - это переписывать нативные ф-ции php.
 

fixxxer

К.О.
Партнер клуба
Ну, вообще ты правильно мыслишь, registry это просто объектная обертка по сути идентичная globals.

Но дело в том, что таких глобальных переменных у тебя, при правильной архитектуре, должно быть от нуля до максимум 3-4 (например, соединение с базой, логгер и т.п.); и избавляться надо, не заменяя слово global словом registry, а пересмотром архитектуры.

Например, вот это
Код:
$GLOBALS['registry']['title'] .= ' - новости'
полный п-ц.

Почитай вот это

http://wiki.agiledev.ru/doku.php?id=ooad:manage_dependencies_in_php_code

Хотя наверное тут лучше начать с книжек по object oriented design-у php-приложений. Вроде тут советовали, поюзай поиск.
 

sverel

Новичок
$GLOBALS['registry']['title'] .= ' - новости'
Ну это лишь пример, который, я надеюсь, всем сразу понятен. Конечно, я так не пишу.
Основная идея топика заключается, в том, что Zend_Registry это класс переписывающий стандартные конструкции языка. Не понятно, зачем? Можно с таким же успехом переписать оператор сложения:
// до:
$x = 5 + 8;
// после
$x = Calc::sum(5, 8);

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

craz

Нестандартное звание
$GLOBALS['registry']['title'] .= ' - новости'
Ну это лишь пример, который, я надеюсь, всем сразу понятен. Конечно, я так не пишу.
Основная идея топика заключается, в том, что Zend_Registry это класс переписывающий стандартные конструкции языка. Не понятно, зачем? Можно с таким же успехом переписать оператор сложения:
// до:
$x = 5 + 8;
// после
$x = Calc::sum(5, 8);

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

atv

Новичок
http://framework.zend.com/manual/en/zend.registry.using.html

PHP:
$refistry->title .= '- новости';
if (! empty($registry->currentSession) && !empty($registry->currentSession['metaKeyWords'])) {...}
глобальных переменных у тебя, при правильной архитектуре, должно быть от нуля до максимум 3-4
Очень спорное утверждение. В конечном приложении приходиться создавать множество объектов и их нужно где-то хранить. То что некоторые рассовывают эти объекты по классам а потом обращаются к ним как $this->someContainer->someObject, а потом ещё делают для этого вызова обёртку $this->getSomeObject(), проблемы хранения большого кол-ва объектов не решает. В конце концов, в чём различие $registry->someObject или $this->getSomeObject().
 

fixxxer

К.О.
Партнер клуба
различие в увеличении количества связей

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

sverel

Новичок
atv
Вы забыли объявить переменную $registry и в итоге код у Вас не на много короче моего примера:
PHP:
// Первый
$registry = Zend_Registry::getInstance();
$registry->title .= '- новости';

// Второй
$registry = Zend_Registry::getInstance();
if (! empty($registry->currentSession)
  && !empty($registry->currentSession['metaKeyWords'])) {
}

// Всё равно в 3 раза сложнее, чем
if ( ! empty($GLOBALS['registry']['currentSection']['metaKeyWords'])) { ... }
 

craz

Нестандартное звание
блин че у вас в голове? какая разница вообще в вашем коде, который вы приводите, вы понимаете? делайте как вам удобнее - меня к примеру тупо пробешивает $GLOBALS в коде - хотя бы потому что капсом написана переменная
 

sverel

Новичок
Т.е. вы используете пачку классов только из-за капса?
 
  • Like
Реакции: Koc

Koc

Новичок
на самом деле я тоже не вижу смысла в реестре. Вот IoC-контейнер это да, совсем другое дело.
 
Сверху