我有一个使用标准PHP构建的Web应用程序。我正在通过使用Symfony2构建子应用程序(对于站点的管理员/所有者)来学习Symfony。到目前为止这么好..
我的symfony应用程序确实调用了来自“父”应用程序的一些初始化代码,并且该初始化代码设置了这个子应用程序可能或可能不想使用的一些(遗留)会话变量。
但我在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超全局有点像反模式) - 或者,是否存在可能导致的任何其他特定的不兼容性或问题来自我的“父”应用程序的代码使用遗留会话这一事实?还是其他一些/其他原因?
答案 0 :(得分:5)
它实际上是在http://symfony.com/doc/current/components/http_foundation/session_php_bridge.html上解释的,但它并不那么明显:
SF2也使用了$ _SESSION,但它“封装”了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%避免与遗留代码冲突,这就是为什么他们指出它并提出解决方案如何处理这种问题