php - 为什么 Symfony2 建议避免使用 'legacy' php session ？

Question

我有一个使用标准 PHP 构建的 Web 应用程序。我正在通过使用 Symfony2 构建子应用程序(针对网站的管理员/所有者)来学习 Symfony。到目前为止一切顺利..
我的 symfony 应用程序确实从“父”应用程序调用了一些初始化代码，并且该初始化代码设置了该子应用程序可能想要也可能不想使用的一些(遗留) session 变量。

但我在 Symfony 文档中注意到他们建议避免使用旧版 PHP session 。 http://symfony.com/doc/current/components/http_foundation/sessions.html http://symfony.com/doc/current/components/http_foundation/session_php_bridge.html

他们为什么提出这个建议？

这仅仅是因为 Symfony session 管理“更好”吗(并且使用遗留的 SESSION 超全局在某种程度上是一种反模式)——或者，是否存在任何其他特定的不兼容或问题可能导致我的“父”应用程序中的代码正在使用旧 session 这一事实？或者其他/额外的原因？

Answer 1

实际上在 http://symfony.com/doc/current/components/http_foundation/session_php_bridge.html 上对此进行了解释，但不是那么明显:

1. SF2 也使用了 $_SESSION，但它将功能“封装”在 session 服务中。您不必担心 session_start 以及所有这些 - 只需正确配置它，然后通过服务访问它即可。

2. 文档提到了存储 session 数据的“包”。这些“包”是具有 SF 特定结构的数据容器。如果旧服务完全控制 $_SESSION，则可能会损坏这些结构。另一方面，遗留服务可能会创建 SF2 不知道的结构，并且可能会损坏。

例如，这是 Symfony2 中 print_r(array_keys($_SESSION)); 的结果:

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

总的来说，我不会说 SF 的 session 处理更好或更差 - 作为一个框架，它只是为 session 管理的常见问题提供了实现。

最多，它可以被认为优于“天真的”实现，特别是对于(抱歉:)“PHP 新手”来说，他们不了解 session 处理的所有含义。

由于 session 的性质(尤其是 PHP 中的 $_SESSION 超全局变量)，您无法 100% 避免与遗留代码发生冲突，这就是为什么他们指出这一点并提出解决方案处理此类问题。