Zend Registry utilisation

Bonjour,

J'ai lu que Zend_Registry, il ne fallait pas y abuser. Il est vrai que dans un cas extrême, on pourrait avoir :

Zend_Registry::get('Zend_View')->...
Zend_Registry::get('Zend_Request')->...

Ce qui fonctionnerait certainement assez bien, mais pas vraiment logique. Seulement, c'est un peu comme les Singleton : on dit qu'ils sont à utiliser pour interdire l'instanciation multiple, souvent par rapport à la "sécurité", d'autres parlent aussi de "performances", d'autres soutiennent plus ou moins leur qualité en tant qu'objet accessible partout. Là encore, un gros débat là-dessus. Pour l'instant, je me cantonne à l'instanciation unique pour sécurité voire performances mais jamais par accessibilité, mais c'est pas fixé ;) (ps : le singleton, c'est bien, mais j'ai quand même eu une periode de Singletonite où tout était Singleton).


Donc on se retrouve avec plusieurs possibilités pour les objets : Le registre, la dépendance à un autre / association (en étant attribut d'un objet), ou l'instanciation systématique.

Par exemple, Zend_Db_Table (de mémoire) s'instancie autant de fois que d'utilisation (mais là, je commence le projet, à voir donc dans quelles circonstances).

Par contre, ma question réelle, c'est le Zend_Session_Namespace. Par exemple, je l'instancie dans mon bootstrap (hé oui, j'en ai besoin à chaque page), dois-je l'injecter dans la vue et le controlleur pour récupérer l'instance ? Dois-je l'enregistrer dans le registre et aller le chercher à chaque fois ? Dois-je l'instancier comme il est si facile de le faire ?

Dans le coté j'instancie systématiquement, ce qui me gène un peu c'est ce côté "new ..." comme si je créais. Or, je ne le crée pas, il existe. Meme s'il pointe sur un même contenu, ça me paraît pas d'une logique énorme (d'ailleurs j'y pense : kezako si je le mets en lecture seule ? A voir dans le Code source). Si je le mets dans le registre, ça me choque pas. Mais je me souviens de la phrase ... Par ailleurs, actuellement, je l'ai instancé dans le bootstrap et l'ai injecté directement dans la vue.

Voilà, je pourrais disserter pendant des heures, mais je crois que vous avez déjà assez souffert. Je vous laisse m'éclairer ;)

Merci et a+ !

En ce qui concerne le singleton c'est aussi pour ne pas réinstancer plusieurs fois, on récupère l'instance déjà existante.

Je n'ai pas trop regarde au niveau de Zend_Registry mais j'ai l'impression que c'est un peu comme une mise en session.

Il n'est pas utile de déclarer ton Zend_Session_Namespace dans le bootstrap même si tu en as besoin sur toutes tes pages, c'est le principe des sessions.

À partir du moment ou tu créer dans une page un Zend_Session_Namespace tu peux le récupérer dans l'autre en lui l'instanciant avec le même nom.

Si dans une page tu déclare :

Code:

---

1 2	$session = new Zend_Session_Namespace('session1');

---

Tu peux donc récupérer dans une autre page, de la façon suivante :

Code:

---

1 2	$session = new Zend_Session_Namespace('session1');

---

C'est à se demander pourquoi Zend_Registry est Singleton, s'il suffit de travailler sur le static, il n'y a plus aucune incohérence à l'instancier à chaque utilisation, puisqu'il travaille sur une source externe de données (sur le static) tout comme Zend_Session_Namespace (qui, lors d'un vérrouillage, le fait sur le static pour que toutes les instances en "profitent").

Imaginons qu'il n'y ait pas de singleton, comment fait tu pour garder toujours la même instance ?

Si tu déclare une nouvelle instance, tu perdrais tout ce qui est la l'instance précédente.

Tu serais donc obliger de le stocker en session et dans ce cas là tu devras sérialiser ton instance et le dé-sérialiser ensuite, etc...

À ton avis vaut mieux ça ou un singleton?

Zend_Registry n'a pas besoin de Singleton pour faire son job, il pourrait tout faire en static, et d'ailleurs c'est en static que je l'utilise. Pour moi c'est un outil, il n'a pas de vie. Cependant, ils ont fait le choix de le mettre en objet, condition sine qua non à l'implémentation de l'héritage de ArrayObject. Du coup, ils doivent passer à l'objet, et là il y aurait incohérence à en instancier plusieurs. Ils auraient aussi pu travailler que sur le static, mais j'imagine que ça perd de son sens ici.

D'ailleurs, assez drôle, Zend_Registry dans son code utilisé l'objet même dans ses méthodes statiques (il fait appel à son propre getInstance()), alors qu'il n'est pas destiné à être multiton (pluriton ;)), à côté Zend_Session_Namespace qui autorise plusieurs instances vers la même donnée utilise le statique dans ses méthodes d'objet pour garder le même état des instances. En quelque sorte, totalement le contraire. Ca me fait presque penser à faire un new Voiture('rouge') qui renverrait l'instance d'une instanciation précédente de la même couleur. Ce qui est bien, et à la fois pas, c'est que l'on peut faire la même chose en 58 façons différentes avec Zend. Zend_Session_Namespace permet tout à fait d'instancier en singleton. Quand on est anxieux comme moi et que l'on a pas 30 ans de développement derrière soit, ça créé forcément plein de questions (mais j'ai pas attendu le framework pour ça ;)).

Je me permets de citer ma question d'origine pour se reconcentrer sur le sujet (ceux qui n'ont pas déjà répondu) :

Citation:

---

Par contre, ma question réelle, c'est le Zend_Session_Namespace. Par exemple, je l'instancie dans mon bootstrap (hé oui, j'en ai besoin à chaque page), dois-je l'injecter dans la vue et le controlleur pour récupérer l'instance ? Dois-je l'enregistrer dans le registre et aller le chercher à chaque fois ? Dois-je l'instancier comme il est si facile de le faire ?

---

Zend_Session_Namespace n'a pour but que d'encapsuler l'accès à un namespace de session et d'y implémenter l'interface IteratorAggregate.
Dans cette logique il est donc normal que cela ne soit pas du simple accès static (impossible d'ailleurs avec IteratorAggregate).

Par contre c'est à toi de choisir si tu veux interdire l'instanciation multiple d'un même namespace via la seconde option du constructeur.
En gros Zend_Session_Namespace te permet un large choix de politique de gestion de tes namespaces ... (personnellement, j'instancie)

Pour ton exemple de voiture rouge, je dirais plus que c'est un new Cles('voiture_rouge');
Car tu peux avoir plusieurs jeux de clés pour la même voiture équipée de la fermeture centralisée. Chaque clé est une instance qui agit sur un même objet voiture.

Le pattern Registry en php (à mon sens) n'as d'utilité que dans l'aspect registre de configuration d'une application, l'utiliser comme raccourci ou par facilité amène plus de problème qu'autre chose (dépendance, couplage, lisibilité, compréhension...).

Citation:

---

Envoyé par devlop78

Zend_Registry n'a pas besoin de Singleton pour faire son job, il pourrait tout faire en static, et d'ailleurs c'est en static que je l'utilise. Pour moi c'est un outil, il n'a pas de vie. Cependant, ils ont fait le choix de le mettre en objet, condition sine qua non à l'implémentation de l'héritage de ArrayObject. Du coup, ils doivent passer à l'objet, et là il y aurait incohérence à en instancier plusieurs. Ils auraient aussi pu travailler que sur le static, mais j'imagine que ça perd de son sens ici.

D'ailleurs, assez drôle, Zend_Registry dans son code utilisé l'objet même dans ses méthodes statiques (il fait appel à son propre getInstance()), alors qu'il n'est pas destiné à être multiton (pluriton ;)), à côté Zend_Session_Namespace qui autorise plusieurs instances vers la même donnée utilise le statique dans ses méthodes d'objet pour garder le même état des instances. En quelque sorte, totalement le contraire. Ca me fait presque penser à faire un new Voiture('rouge') qui renverrait l'instance d'une instanciation précédente de la même couleur. Ce qui est bien, et à la fois pas, c'est que l'on peut faire la même chose en 58 façons différentes avec Zend. Zend_Session_Namespace permet tout à fait d'instancier en singleton. Quand on est anxieux comme moi et que l'on a pas 30 ans de développement derrière soit, ça créé forcément plein de questions (mais j'ai pas attendu le framework pour ça ;)).

Je me permets de citer ma question d'origine pour se reconcentrer sur le sujet (ceux qui n'ont pas déjà répondu) :

---

Des mon premier message j ai répondu à ta question, et c est le deuxieme topic que tu fais divaguer.

Donc merci d etre clair dans tes messages et de te recentrer