我最近遇到了一个 ASP 1.1 Web 应用程序，它在会话变量中放置了一大堆东西——包括所有 DB 数据对象，甚至是 DB 连接对象。它最终变得巨大。当 Web 会话超时（用户使用完应用程序后四个小时）时，有时他们的数据库事务会回滚。我假设这是因为当 IIS 终止会话时数据库连接没有正确关闭。
无论如何，我的问题是会话变量中应该包含什么？显然有些东西需要在那里。用户在主屏幕上选择他们想要编辑的计划，因此计划 ID 进入会话变量。通过将有关用户（及其经理等）的所有详细信息以及他们正在编辑的计划存储在会话变量中来尝试减少数据库的负载是否更好，或者我应该尝试最小化会话变量中的内容和在 Page_Load 事件中查询数据库以获取我需要的所有内容？
这很难回答，因为它是特定于应用程序的，但这里有一些我使用的指南：
根据您对应用程序的介绍，我可能会从数据库中选择您的数据，并尝试找到将这些查询的影响降至最低而不是加载会话的方法。
不要将数据库连接信息放在会话中。
至于缓存，如果可能的话，我会避免使用会话进行缓存——你会遇到其他人更改用户正在使用的数据的问题，而且你不能在用户之间共享缓存的数据。使用 ASP.NET 缓存或其他一些缓存实用程序（如 Memcached 或 Velocity）。
至于会话中的内容，适用于用户打开到您网站的所有浏览器窗口的任何内容（登录、安全设置等）都应该在会话中。诸如正在查看/编辑什么对象之类的事情实际上应该是在屏幕之间传递的 GET/POST 变量，因此用户可以使用多个浏览器窗口来处理您的应用程序（除非您想阻止这种情况）。
除此之外，我会说它会有所不同。如果您不使用进程中会话，太多的会话会减慢您的速度，因为您将序列化很多 + 提供程序的速度。应该谨慎使用缓存和会话。不要仅仅因为您可以或方便而参加会议。坐下来分析是否有意义。
理想情况下，ASP 中的会话应该存储您可以逃脱的最少数据量。存储对保持系统资源打开（尤其是数据库连接）的任何对象的引用是一个明确的可伸缩性杀手。此外，在大多数情况下，将未提交的数据存储在会话变量中只是一个坏主意。总的来说，听起来当前的实现正在滥用会话对象来尝试在所谓的无状态环境中模拟有状态的应用程序。
尽管受到了很多诟病，但通过隐藏字段自动管理状态的 ASP.NET 模型应该真正消除了在会话变量中保留任何内容的大部分需要。
我的经验法则是，应用程序需要的可扩展性（就用户/点击数而言）越多，使用会话状态的机会就越少。但是，有一个权衡。对于用户重复访问相同数据并且每次使用站点通常具有相当长的会话的 Web 应用程序，一些缓存（如果需要在会话对象中）实际上可以通过减少数据库服务器上的负载来帮助可伸缩性。这里的想法是，与后端 DB 相比，耕种表示层更便宜且更简单。当然，无论如何，这个建议应该适度接受，并不适用于所有情况，但对于一个相当简单的内部 CRUD 应用程序，它应该很好地为您服务。
之前就 PHP 会话提出了一个非常相似的问题。基本上，会话是存储用户特定数据的好地方，您需要在多个页面加载时访问这些数据。会话不是存储数据库连接引用的好地方；您最好使用某种连接池软件或在每次页面加载时打开/关闭您的连接。至于在会话中缓存数据，这取决于会话数据的存储方式、您需要多少安全性以及数据是否特定于用户。更好的选择是使用其他东西来缓存数据。
在会话中存储导航提示很棘手。同一个用户可以打开多个窗口，然后更改以令人困惑的方式传播。绝对不应该存储数据库连接。ASP.NET 为您维护连接池，无需求助于您自己的巫术。如果您需要短期缓存内容并且数据集大小相对较小，请查看 ViewState 作为一个可能的选项（以在页面大小上加载更多批量为代价）
答：仅与一位用户相关的数据。IE：一个用户名，一个用户ID。最多代表一个用户的对象。有时，与 URL 相关的数据（例如将某人带到哪里）或错误消息堆栈对于推送到会话中很有用。
如果您想在不同用户之间共享内容，请使用应用程序商店或缓存。他们远超一流。
斯蒂芬，
您是否为一家以“I”开头的公司工作，该公司的网站以“BC”开头？这听起来和我刚开始在 .net 中开发时所做的完全一样（当时我年轻而愚蠢）——我在会话和应用程序中塞满了我能想到的一切。不用说，那是双重的不利因素。
一般来说，尽可能避开会话。当然，不可序列化的对象不应该存储在那里（数据库连接等），但即使是大的、可序列化的对象也不应该是。你只是不想要开销。
我总是在会话中保留很少的信息。会话使用昂贵的服务器内存资源。在会话中保存太多值会增加服务器的负载，最终站点的性能会下降。当您使用负载平衡服务器时，会话的使用可能会遇到问题。所以我所做的是使用最少的会话或不使用会话，如果信息不是很关键，则使用 cookie，更多地使用隐藏字段和数据库会话。