为什么Symfony2建议避免使用'传统'php会话？

我有一个使用标准PHP构建的Web应用程序。我通过使用Symfony2构建一个子应用程序（针对网站的管理员/所有者）来学习Symfony。到目前为止这么好..
我的symfony应用程序确实调用了'父'应用程序的一些初始化代码，并且初始化代码设置了这个子应用程序可能或不想使用的一些（遗留）会话变量。为什么Symfony2建议避免使用'传统'php会话？

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

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

仅仅是因为Symfony会话管理是“更好的”（并且使用旧版SESSION超全局有些反模式）---或者是否有任何其他特定的不兼容或可能导致的问题由于我的'父''应用程序中的代码使用传统会话？或者其他一些/额外的原因？

来源

2014-09-13 Eddie

它实际上是在http://symfony.com/doc/current/components/http_foundation/session_php_bridge.html解释，但它不是那么明显：

SF2还使用了$ _SESSION，但它“encapsules”功能在session服务。您不必担心session_start以及所有这些 - 只需对其进行正确配置，然后通过服务访问它。
该文档提到了会话数据存储在其中的“行李”。这些“行李”是具有SF特定结构的数据容器。如果传统服务可以完全控制$_SESSION，则可能会损坏这些结构。另一方面，传统服务可能会创建SF2不知道的结构，并且可能会损坏。

例如，这是在Symfony2中一个print_r(array_keys($_SESSION));的结果：

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

在一般情况下，我不会说，SF的会话处理是好还是坏 - 作为一个框架，它只是为会话管理的常见问题提供了一个实现。

最多可以认为它优于“天真”的实现，尤其是（对不起）“PHP新手”，他们不理解会话处理的所有含义。

由于会话的性质（尤其是PHP中的$_SESSION超全局），您无法100％避免与遗留代码发生冲突，这就是为什么他们指出并提出解决方案来解决如何处理这类问题的原因。

来源

2014-09-13 19:25:52 lxg

他们在应用程序的生命周期中对变量做了很多事情，不仅$ _SESSION被操纵，还有$ _FILES（今天我对此有些头痛的处理），如果你去symfony的github回购你可以更好地理解他们为什么这么做 – ROLO 2014-09-13 19:31:40

为什么Symfony2建议避免使用'传统'php会话？

回答

相关问题