Как решить конструктор внедрения Zend\Session?

Question

Архитектура компонента Session в Zend Framework 2 еще не документирована, и у меня возникли некоторые затруднения с пониманием его практического использования (по сравнению с очень интуитивно понятным сеансом Symfony, например).

Краткое резюме важных частей:

• Zend\Session\Storage\SessionStorage карты и заменяет $_SESSION суперглобальный
• Zend\Session\SessionManager является фасадом для управления хранилищем, файлами cookie сеанса, конфигурацией сеанса, проверкой сеанса и т. д.
• Zend\Session\Container это своего рода замена старого Session_Namespaceразные Контейнеры совместно используют один экземпляр Manager (через статическое поле).

Нет компонента, представляющего коллекцию пространств имен (контейнеров), и, следовательно, нет способа использовать такие методы, как 'issetNamespaceX', 'unsetNamespaceX' и т. Д. Никто (включая Manager и Storage) не знает о контейнерах, есть ли любые, и если, сколько с какими именами.

Мэтью Вейер О'Финни объяснил это обстоятельство следующим образом:

Контейнер - это специальный класс для работы с изолированными сегментами текущего экземпляра Storage. [...] Если что, адаптер хранения будет содержать контейнеры, а не диспетчер. Однако мы также хотим разрешить более простое использование хранилища, что делает контейнер ортогональным к хранилищу и объясняет разницу в отношениях has-a.

Я вижу несколько практических проблем с этим решением в отношении правильного внедрения зависимости. Очевидно, что Менеджер можно рассматривать как сервис с довольно длительным сроком службы, и, следовательно, он подходит для внедрения в конструктор. К сожалению, Менеджер не имеет ни малейшего представления о контейнерах, что вынуждает меня также вводить контейнеры (что плохо, потому что они недолговечны и убирают слоты), писать свои собственные дополнительные функции, чтобы сделать хранилище или менеджер Контейнера осведомленным (должен быть фреймворком функциональности) или создайте контейнеры в моих классах потребления (которых я, очевидно, хочу избежать).

Поэтому решение Zend не кажется мне практичным. Если я хочу использовать Manager, FlashMessenger и дополнительный контейнер, мне нужно добавить 4 (четыре!) Класса. Если я делаю то же самое с сеансом Symfony, мне нужно только добавить 1 (один) класс.

Кроме того, контейнеры не подходят для внедрения, так как они потенциально недолговечные объекты времени выполнения, которые могут существовать или не существовать в данный момент во время выполнения скрипта. С Сессией Symfony это не проблема, так как Сессия знает о своих сумках (контейнерах), с ZF2 это проблема, так как Менеджер НЕ знает о Контейнерах.

---

Основной вопрос: как я должен использовать Zend\Session with Containers на практике?

Дополнительный вопрос: есть ли веская причина не предоставлять реальную функциональность пространства имен, подобную ZF1 или, например, аналогичную Symfony? SessionBag?

Answer 1

Я не уверен на 100%, что понимаю, с какими проблемами вы сталкиваетесь.

Во-первых, конструктор для Container принимает как пространство имен для контейнера, так и опционально Manager пример: $container = new Container('your container namespace here', $manager), Вы можете также указать экземпляр менеджера по умолчанию: Container::setDefaultManager($manager),

Во-вторых, Container представляет просто именованный массив внутри Storage экземпляр используется. Таким образом, вы можете проверить наличие контейнера, выполнив isset($storage['your container namespace here']) вызов.

Какие именно проблемы вы сталкиваетесь с тем, что вышеописанное не решает? Из вашего описания звучит так: (а) вы не знали, что контейнеры имеют отношение 1:1 к хранилищу, и (б) что вы можете добавить менеджера в экземпляры контейнера. Если есть дополнительные проблемы, я бы хотел лучше их понять.