我最近遇到了一个ASP 1.1 Web应用程序，它在会话变量中放入了大量内容 - 包括所有数据库数据对象甚至数据库连接对象。它最终变得巨大。当Web会话超时（用户使用完应用程序四小时后），有时会回滚其数据库事务。我假设这是因为当IIS终止会话时，数据库连接没有正确关闭。
无论如何，我的问题是会话变量应该是什么？显然有些事情需要在那里。用户在主屏幕上选择要编辑的计划，因此计划ID将进入会话变量。通过存储有关用户（及其管理员等）的所有详细信息以及他们在会话变量中编辑的计划来尝试减少数据库的负载是否更好？或者我应该尝试最小化会话变量中的内容查询数据库中我在Page_Load事件中需要的一切吗？
答案 0 :(得分：5)
这很难回答，因为它是特定于应用程序的，但这里有一些我使用的指南：
从您对应用程序的说法很少，我可能会从数据库中选择您的数据并尝试找到最小化这些查询影响的方法，而不是加载会话。
答案 1 :(得分：5)
不将数据库连接信息放入会话中。
就缓存而言，如果可能的话，我会避免使用会话进行缓存 - 你会遇到其他人更改用户正在使用的数据的问题，而且你无法在用户之间共享缓存的数据。使用ASP.NET Cache或其他一些缓存实用程序（如Memcached或Velocity）。
至于应进入会话的内容，适用于用户已对您的网站开放的所有浏览器窗口的任何内容（登录，安全设置等）应该在会议中。正在查看/编辑对象的内容应该是在屏幕之间传递的GET / POST变量，这样用户就可以使用多个浏览器窗口来处理您的应用程序（除非您想要阻止它）。
答案 2 :(得分：2)
答案 3 :(得分：1)
理想情况下，ASP中的会话应该存储您可以获得的最少量的数据。存储对任何打开系统资源的对象（特别是数据库连接）的引用是一个明确的可伸缩性杀手。此外，在大多数情况下，将未提交的数据存储在会话变量中只是一个坏主意。总的来说，听起来当前的实现是滥用会话对象来尝试在所谓的无状态环境中模拟有状态应用程序。
虽然它受到很多诽谤，但是通过隐藏字段自动管理状态的ASP.NET模型应该真正消除了在会话变量中保留任何内容的大部分需求。
我的经验法则是，应用程序需要的可伸缩性（就用户/点击量而言）越多，使用会话状态就越少。然而，有一个权衡。对于用户重复访问相同数据并且通常每次使用站点具有相当长的会话的Web应用程序，一些缓存（如果需要在会话对象中）实际上可以通过减少DB服务器上的负载来帮助扩展。这里的想法是，与后端数据库相比，播放表示层要便宜得多，也不那么复杂。当然，对于所有事情，这个建议应该适度，并不适用于所有情况，但对于一个相当简单的内部CRUD应用程序，它应该很好地为你服务。
答案 4 :(得分：0)
先前询问了有关PHP会话的very similar question。基本上，Sessions是存储用户特定数据的好地方，您需要跨多个页面加载访问这些数据。会话不是存储数据库连接引用的好地方;你最好使用某种连接池软件或在每个页面加载时打开/关闭你的连接。就会话中的缓存数据而言，这取决于会话数据的存储方式，所需的安全性以及数据是否特定于用户。更好的选择是使用其他东西来缓存数据。
答案 5 :(得分：0)
在会话中存储导航提示很棘手。同一个用户可以打开多个窗口，然后以混乱的方式传播更改。数据库连接肯定不能存储。 ASP.NET为您维护连接池，无需借助自己的魔法。如果您需要在短时间内缓存内容并且数据集大小相对较小，请将ViewState视为可能的选项（代价是将更多批量加载到页面大小上）
答案 6 :(得分：0)
A：仅与一个用户相关的数据。 IE：用户名，用户ID。 最多表示用户的对象。有时，URL相关数据（比如把某人拿走）或错误消息堆栈对于推进会话很有用。
如果要在不同用户之间共享内容，请使用应用程序商店或缓存。他们远远优越。
答案 7 :(得分：0)
泉，
你是否为一家以“我”开头的公司工作，该公司的网站以“BC”开头？这听起来就像我第一次开始使用.net（并且年轻而愚蠢）时所做的那样 - 我在会话和应用程序中塞满了我能想到的一切。毋庸置疑，这是双加不良的
一般来说，尽可能避免会话。当然，不可序列化的对象不应该存储在那里（数据库连接等），但即使是大的，可序列化的对象也不应该存储。你只是不想要开销。
答案 8 :(得分：0)
我会在会话中保留很少的信息。会话使用昂贵的服务器内存资源。在会话中保存太多值会增加服务器上的负载，并且最终会导致站点性能下降。使用负载平衡服务器时，会话的使用可能会遇到问题。所以我所做的是使用最少或没有会话，如果信息不是很关键则使用cookie，更多地使用隐藏字段和数据库会话。