爲什麼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會話？

回答

相關問題