ASP.NET中会话中真正存储的是什么？

我们正试图决定如何处理跨回的对象持久性访问，以避免在每个请求中从数据库获取数据，我倾向于使用会话（它是一个intranet应用程序，不会有成千上万的用户），但这是因为我怀疑只有对真实对象的引用存储在那里

有人知道这是真的吗

我一直被教导不要过度使用session对象，但如果它以这种方式工作，那就不是什么大问题了

此处会话中真正存储的内容：

Session["myKey"] = myObject;

---

实际的序列化对象或其引用？

ASP.NET会创建一个默认情况下存储在cookie中的GUID（但您可以指定查询字符串的使用）来标识用户。默认情况下，与该cookie关联的对象存储在IIS进程内的服务器上

您还可以创建自定义会话对象存储（会话状态存储提供程序），例如，如果您希望将会话对象排除在进程之外

更多信息请点击此处：

但要回答你的问题

开箱即用，假设会话存储只存储对对象的引用是正确的

尽管如此，我相信您可以在web.config中指定会话功能的存储行为，以实现序列化。三种模式：

• InProc-会话作为活动对象保留在web服务器中（aspnet_wp.exe）。使用web.config中的“cookieless”配置将sessionId“munge”到URL上（也解决了cookie/domain/path RFC问题！）
• StateServer—会话序列化并存储在单独进程（aspnet_state.exe）中的内存中。状态服务器可以在另一台计算机上运行
• SQLServer-会话序列化并存储在SQLServer中

---

以上内容来自：

这取决于您使用的会话，如果您在会话中使用inproc会话，您确实在会话中选择了引用，但当引用它自身时，它只是指向一个对象的链接，它将整个对象保留在进程内存中，所以，在设计应用程序时，非常希望知道每个用户将拥有多少数据，以及每个小时将拥有多少活动用户。如果在proc会话中使用，则进程内存中的对象不会序列化，但如果在proc会话外使用，则会序列化该对象，它可能会对性能产生影响

---

我认为在这里您可以找到非常好的

记住，进程会话中的数据非常脆弱，这意味着它可能在您最需要它的时候不存在。如果工作进程因任何原因而被回收，那么它就消失了。

我知道您现在没有太多的性能问题，会话可能会正常工作；但是，还有其他方法可以在回发中维护状态或携带数据

如果您试图跨同一页面的回发持久化数据，那么我建议改用ViewState。请注意，存储在ViewState中的数据是序列化的，任何要持久化的对象都必须实现ISerializable。

我尝试了以下方法：

我已经创建了一个类，并在会话中存储了该类的一个实例（会话状态模式：InProc）。实例位于aspnet_wp.exe进程中

然后，我将会话状态更改为SQL Server（仍然没有[Serializable]属性），并得到以下错误

无法序列化会话状态。在“StateServer”和“SQLServer”模式下，ASP.NET将序列化会话状态对象，因此不允许使用不可序列化的对象或MarshalByRef对象。

因此，inProc会话状态没有序列化

干杯。。。

---

Martín

有大量文章和博客文章哀叹在会话变量中存储复杂对象（技术上存储对所述对象的引用）。一般来说，我认为会话变量是魔鬼的工作，我会尽我所能避免它们

这就是说，对于一个内部网部署的应用程序，开发人员完全理解胡安·曼努埃尔（Juan Manuel）所描述的过度使用会话对可伸缩性的影响，我已经做了很多次，并且取得了巨大的成功。是的，会话可以重设样式，但这是一个不寻常的边缘情况——它的发生频率不足以影响具有rational会话超时的浏览器应用程序

---

胡安·曼努埃尔，我想说按照你建议的方式构建应用程序，至少一开始是这样。但是，将保存和从会话中获取对象的位置隐藏起来（可能使用包装器类），以便应用程序需要时，以后可以很容易地进行更改。

这也是我的想法，有什么方法可以测试它吗？您可以使用内存分析器来检查此行为，但我想强调在进程会话中存储对象会增加内存消耗，如果您计划在不同用户之间共享数据，最好使用.net内置缓存什么内置缓存？所有用户都共享HttpResponse.Cache，就像应用程序对象缓存一样。。。这是更糟糕的只是你说的，它只适用于同一页回发。。。此外，物体必须在每一根柱子上来回移动。但无论如何，谢谢你是对的，不清楚你是想在一个页面中保持状态，还是要在不同的页面中进行。如果是这种情况，那么如果工作进程进行回收，您将获得不会丢失对象的好处。祝你好运没关系。。。我会再去拿的。。。目标是避免每次都这样做是的，我计划使用包装器类。谢谢你的反馈