为什么Symfony2建议避免使用'遗留'php会话？

Question

I have a web application built with standard PHP. I'm learning Symfony by building a sub-application (for administrators/owners of the site) using Symfony2. So far so good..
My symfony app does call some initialization code from the 'parent' application, and that initialization code sets some (legacy) session variables that this child application may or may not want to use.

But I've noticed in the Symfony documentation that they recommend avoiding use of legacy PHP sessions. http://symfony.com/doc/current/components/http_foundation/sessions.html http://symfony.com/doc/current/components/http_foundation/session_php_bridge.html

Why do they make this recommendation?

Is it simply because the Symfony session management is "better", (and use of the legacy SESSION superglobal is somewhat of an anti-pattern) --- or, is there any other specific incompatibility or problem that may be caused due to the fact that code from my 'parent' application is using legacy sessions? Or some other / additional reasons?

Answer 1

It's actually explained on http://symfony.com/doc/current/components/http_foundation/session_php_bridge.html, but it's not so obvious:

1. SF2 also used the $_SESSION, but it “encapsules” the functionality in the session service. You don't have to worry about session_start and all that – just configure it properly, and then access it via the service.

2. The documentation mentions “bags” wherein the session data is stored. These “bags” are data containers with a SF-specific structure. If a legacy service would take full control over the $_SESSION, it could damage these structures. On the other hand, legacy services might create structures which SF2 is not aware of, and might damage.

For example, this is the result of a print_r(array_keys($_SESSION)); in Symfony2:

Array
(
    [0] => _sf2_attributes
    [1] => _sf2_flashes
    [2] => _sf2_meta
)

In general, I wouldn't say that SF's session handling is better or worse – as a framework, it simply provides an implementation for the common problem of session management.

At most, it could be considered superior to “naive” implementations, especially by (sorry:) “PHP newbies”, who don't understand all the implications of session handling.

And due to the nature of sessions (especially with the $_SESSION superglobal in PHP), you cannot 100% avoid collisions with legacy code, which is why they point it out and propose solutions how to handle this kind of problem.