我只是想通知我实际上可以在$ _SESSION中存储对象,我发现它非常酷,因为当我跳转到另一个页面时,我仍然有我的对象.在我开始使用这种方法之前,我想知道它是否真的是一个好主意,或者是否存在潜在的陷阱.
我知道,如果我有一个单一的入口点,我就不需要这样做,但我还没有,所以我没有一个入口点,我真的想保留我的对象,因为我不我失去了我的状态.(现在我还读到我应该编写无状态站点,但我还不了解这个概念.)
因此,在短期:是否确定存储对象的会话,是否有任何问题,它？
编辑:
临时总结:到目前为止,我知道重新创建对象可能更好,即使它涉及再次查询数据库.
进一步的答案可能会更详细地说明这方面!
我知道这个话题已经过时了,但是这个问题不断出现,并没有让我满意:
无论是在$ _SESSION中保存对象,还是根据隐藏在表单字段中的数据重建整个布料,或者每次都从数据库重新查询它们,都使用状态.HTTP是无状态的(或多或少;但请参阅GET与PUT)但几乎所有人都关心Web应用程序需要在某处维护状态.表现得好像把国家推入角落和缝隙相当于某种理论上的胜利是错误的.国家是国家.如果你使用状态,你将失去无国籍所带来的各种技术优势.除非事先知道你应该失去睡眠,否则这不是失眠的原因.
汉克盖伊提出的"双重打击"论点所获得的祝福使我特别沮丧.OP是否构建了分布式负载均衡的电子商务系统？我的猜测是否定的; 并且我将进一步假定序列化他的$ User类,或者其他什么,不会削弱他的服务器无法修复.我的建议:使用对您的应用程序敏感的技术.$ _SESSION中的对象很好,受常识预防措施的限制.如果您的应用突然变成与服务流量相媲美的亚马逊,您将需要重新适应.这就是生活.
只要在调用session_start()时,就已经遇到类声明/定义,或者已经安装的自动加载器可以找到它.否则它将无法从会话存储中反序列化对象.
出于某种原因,HTTP是无状态协议.会话将状态焊接到HTTP上.根据经验,避免使用会话状态.
更新:HTTP级别没有会话的概念; 服务器通过为客户端提供唯一ID并告知客户端在每个请求上重新提交它来提供此功能.然后,服务器将该ID用作Session对象的大哈希表中的键.每当服务器获得请求时,它都会根据客户端随请求提交的ID,从会话对象的哈希表中查找会话信息.所有这些额外的工作都是可扩展性的双重打击(HTTP是无状态的一个重要原因).
Whammy One:它减少了单个服务器的工作量.
Whammy Two:它更难以扩展,因为现在你不能将请求路由到任何旧服务器 - 它们并不都具有相同的会话.您可以将具有给定会话ID的所有请求固定到同一服务器.这并不容易,而且它只是一个单点故障(不是整个系统,而是整个系统的大块).或者,您可以在群集中的所有服务器之间共享会话存储,但现在您有更多复杂性:网络连接内存,独立会话服务器等.
鉴于这一切,您在会话中输入的信息越多,对性能的影响就越大(如Vinko指出的那样).同样正如Vinko指出的那样,如果你的对象不是可序列化的,那么会话就会行为不端.因此,根据经验,避免在会话中放置超过绝对必要的内容.
@Vinko您通常可以通过在您发回的响应中嵌入您正在跟踪的数据并让客户端重新提交它来解决服务器存储状态,例如,在隐藏的输入中向下发送数据.如果您确实需要服务器端状态跟踪,则它应该位于您的后备数据存储区中.
(Vinko补充说:PHP可以使用数据库存储会话信息,并让客户端每次重新提交数据可能会解决潜在的可扩展性问题,但是打开了一大堆安全问题,您必须注意,现在客户端控制所有您的国家)
无法序列化的对象(或包含不可序列化成员的对象)将不会像您期望的那样从$ _SESSION中出来
巨大的会话给服务器带来了负担(每次序列化和反序列化状态都很昂贵)
除此之外,我没有看到任何问题.
根据我的经验,对于比具有某些属性的StdClass更复杂的东西,它通常是不值得的.在给定会话存储的标识符的情况下,反序列化的成本一直不仅仅是从数据库中重新创建.这看起来很酷,但(一如既往),分析是关键.
除非你绝对需要,我建议你不要使用州.如果可以在不使用会话的情况下重建对象,请执行此操作.在Web应用程序中使用状态会使应用程序构建变得更加复杂,对于每个请求,您都必须查看用户所处的状态.当然,有时候您无法避免使用会话(例如:用户必须在会话期间保持登录状态网络应用程序).最后我建议保持会话对象尽可能小,因为它会影响性能以序列化和反序列化大对象.
京公网安备 11010802040832号 | 京ICP备19059560号-6 