The architecture of the Session component in Zend Framework 2 is yet undocumented and I'm having some trouble understanding it's practical use (compared to the very intuitive Symfony Session for example).

A short summary of the important pieces:

  • Zend\Session\Storage\SessionStorage maps and replaces the $_SESSION superglobal
  • Zend\Session\SessionManager is a facade to manage the storage, the session cookies, session configuration, session validation, etc.
  • Zend\Session\Container is a sort of replacement for the old Session_Namespace, different Containers share one Manager instance (via a static field).

There is no component that represents a collection of namespaces (containers) and therefore there is no way of using methods like 'issetNamespaceX', 'unsetNamespaceX', etc. Nobody (including the Manager as well as Storage) knows about the containers, whether there are any, and if, how many with what names.

Matthew Weier O'Phinney explained this circumstance as follows:

The Container is a special class for working with isolated segments of the current Storage instance. [...] If anything, a Storage adapter would contain Containers, not the Manager. However, we also want to allow more basic usage of storage, which makes the Container orthogonal to Storage, and which explains the difference in has-a relations.

I see a couple of practical problems with this solution with regard to proper dependency injection. Obviously the Manager can be seen as a service with a rather long lifetime and therefore qualifies for constructor injection. Unfortunately, the Manager has no clue about the Containers which forces me to either inject Containers as well (bad because rather short lived and takes slots away), write my own additional functionality to make the Storage or the Manager

php dependency-injection zend-framework2 zend-session
Edit
Report