对于新的应用程序，我尽量避免使用它们，只喜欢使用加密或签名的 cookie。这显然只是一种新发现的个人偏好：因为它是另一件可能出故障的事情，而且在为一个网站连续工作两年，让它 24 小时 / 7 天 / 365 天保持在线工作时，这是唯一以令人费解的方式失败的事情。当您尝试将其存储在 out-of-proc 会话中时，还很容易忘记在对象上添加 [Serializable]，在运行时导致它们崩溃。所以，这是另一个需要处理的问题。

话虽如此，我使用会话多年，除了担心始终保持会话存储器运行外，没有任何重大问题。如果您是InProc，每次应用程序池重新启动时都必须担心会话被删除，这可能会导致工作进程内存使用量增加，这是另一个缺点；使用其他方法之一，可以很好地释放指向Web网站的更新，并且不会影响任何客户的当前状态。

我个人没有看到扩展会话方面出现问题，即使在多个服务器上也没有。不过另一方面，我为一家小企业工作[约每秒3个页面访问量]。我认为你通常都是为了某些事情而与数据库交互，获取会话的成本已经在其中了。

因此，使用会话并不是个坏选择，你只需要记住不要过度使用。把它看作服务端的cookie，尝试限制自己在人为的4KB左右的界限。对于现有的应用程序，我当然不会去对其取消会话，但一般来说，我现在更喜欢保持简单，尽量不使用会话。

对于局域网应用，我使用它们（但实际上并不多）。

对于外部应用程序，如果你只有一台服务器，可以使用它们。

对于有大量用户和多台网页服务器在代理平衡器后面的大型应用程序，您可能应该开始思考如何构建您的网站以避免使用它们。我个人会使用的最佳选项是在用户 cookie 中存储加密数据。

ASP.NET 会话状态 FAQ，这将回答拥有会话变量等的积极方面...我试图避免它们用于某些事情，而用于其他事情...因此，对此类问题的答案因情况而异。

我经常使用会话变量，但不用于大型对象。会话变量的问题是，在完成工作时可能会忘记清除它们，或者在代码的各个地方硬编码键。出于这些原因，我将会话变量封装在一个称为“sessionvariables”的对象中并进行访问。当我需要清除它们时，我会在对象中定义一个方法来清除所有会话变量。

与视图状态或查询字符串不同，对于我遇到的大多数情况，它最适合。

我试图避免使用会话，但不至于对应用程序造成不利影响。面对现实吧，有些设计用会话比试图规避它们更好。总的来说，我不会在可以轻松存储在其他地方的地方使用会话。

如果必须使用它们，请使用。在小的用途中，这是一种足够简单的方式在页面之间传递数据，但永远不要把控件放进会话中，特别是在页面之间，否则你只会让自己陷入困境。

我经常用它们来处理小物品，但是随着时间的推移，我最终构建了一个简单的层，它位于会话的顶部，处理清除会话和转换为正确类型、管理键等事情。这也防止了冲突的发生。

有一些东西我不能存储在查询字符串中，有些东西我也不希望存储在视图状态中。现在唯一剩下的就是会话了。

ASP.NET 的会话管理很好，因此不要尝试避免使用它而给自己带来麻烦。ASP.NET 的会话管理功能可以很好地扩展，提供不同的解决方案，具体取决于您的需求。您还应该关注微软的 Velocity 项目。

凯夫