在我以前的工作（ASP.NET Web表单）中，我使用HttpContext.Current.Session对象来保存当前用户会话的安全相关用户数据，例如
Session("userID") = 4525
Session("customerId") = 123
Session("importantValue") = "ABC"
在WebAPI2上学习了很多之后，我现在开始学习MVC。我经常读到MVC应该避免使用Session和/或HttpContext.Current。。。
- 同步和开销
- 会话污染HTTP
- 应用程序冲突
- AppPool回收
但对于简单的替代方案并没有太多的明确性。有些人说使用TempData，而另一些人则使用cookie，但两者都有缺点。
我的应用程序的数据库量很大，所以我希望避免为了每次请求都重新读取这些值而访问数据库。在WebAPI2中，有一些承载令牌被序列化为cookie。身份令牌是否足够安全以保存此数据并避免用户篡改（如果通过SSL使用）？
伙计，我不确定"使用TempData而不是会话"的想法是从哪里来的，但我真的很想找到来源，并用钝器击打它们。TempData是会话。它使用引擎盖下的会话存储。唯一的区别是，放在那里的数据只会保存到下一个请求，而放在Session中的数据会保存到会话到期。否则，就是完全一样的。
也就是说，围绕这个问题有很多争论，其中大部分都被误导了，只会导致进一步的混乱。然而，争论的关键在于，会议是非常糟糕的事情。但是，如果你需要添加一个国家的概念，那就别无选择了。
请参阅，HTTP作为一种协议是无状态的。每个请求都是一个唯一的实体，不受之前或之后任何其他请求的影响。Web API不使用会话，因为它是所谓的"REST-compliant"，因为它遵循REST的准则。而且，REST本身是以HTTP为模型的，也是无状态的。然而，这毕竟是真实的生活，您仍然需要执行身份验证请求之类的操作。因此，像auth令牌之类的东西要么在请求查询字符串或正文中发送，要么通过HTTP头发送。我认为这仍然是"会话"，因为传统会话的工作方式大致相同：您传递一些带有请求的"令牌"，即您的会话id，服务器使用它将您识别为以前请求中的同一客户端。
所以，实际上，当人们争论会话时，他们并不是在争论会话本身的概念，而是在争论它是如何被使用/滥用的，即使他们没有意识到这就是他们所争论的。
我看到其他人争论使用Redis或其他NoSQL选项而不是会话的优点，但你只是在争论会话提供者，而不是会话。
就我个人而言，我认为在MVC项目中使用Session没有错，只要你正确地使用它。它非常适合为经过身份验证的用户创建状态。每当你想从网站请求新页面时，都必须再次登录，这将是非常令人讨厌的。除此之外，我几乎不会管它。实际上，很少有东西应该在多个请求中保持。