是否有最佳实践和推荐替代 MVC 中的 Session 变量

Question

好的，所以首先在任何人试图确定这是一个“重复”问题之前；我已经查看了关于类似问题的大多数关于 SO 的帖子，但即使结合所有已经说过的内容，我仍然有点左右为难，或者我应该对此表示一致同意。

但是，我可以说我（根据帖子）最终确定答案是基于要求的范围。但即使考虑到这一点，对于我应该如何处理这个问题，意见似乎也太多样化了。

我的直接要求是我需要将来自 1 个控制器的变量数据保存在多个视图中。更具体地说，我有一个控制器和相应的视图来处理购物车项目计数，并且我想在多个视图中保留该数据。我认为 _layout 视图是最合乎逻辑的选择。

现在我通过将值分配给从我的 _layout 视图中检索到的 Session 变量成功地完成了这项任务；因此，即使用户在网站内的任何位置导航，购物车中的商品数量也会持续存在，直到他们离开网站或完成结帐为止；在这种情况下，变量将在代码中被清除。

我读过的帖子似乎偏向于要么远离 Session 变量而支持 Cookie，要么将数据存储在数据库中；或说明出于我建议使用它们的目的，Session 变量非常适合使用。

我读到的另一件事表明，如果网站上的流量很高，会话变量可能会阻碍整体性能，因为信息存储在服务器上。

我个人无法证明将此类信息存储在数据库中并随后访问数据库是合理的，因为我认为这也会影响站点性能，并且对于存储临时数据似乎有点矫枉过正。 TempData、ViewData 和 ViewBag 在持久化数据方面不起作用，因此它们不是 IMO 要求的逻辑选择。

如果 Session 变量有另一种非常合适的替代品（对我有用），我想知道它是什么。

在提供最佳建议方面似乎相互矛盾的 2 个帖子让我有点困惑。

缺点：Is it a good practice to avoid using Session State in ASP.NET MVC? If yes, why and how?

优点：Still ok to use Session variables in ASP.NET mvc, or is there a better alternative for some things (like a cart)

似乎这个问题（尽管有许多不同的变体）没有我可以得出的明确答案。

如果有更可取的方式来完成此任务而不会过度杀伤，那么这就是我正在寻找的答案。

我在某处读到了 MVC 过滤器与 Global.ascx 应用程序启动部分的结合使用，但这似乎不适用于在控制器级别设置的变量，而可能是静态变量。

是否有人可能会压制（因为没有更好的词）关于该主题的许多不同意见，并可能为该问题提供更明确的答案？我敢肯定，不同的意见各有所长，我并没有试图抹黑他们。但是有一个明确且可能一致的答案会更好；然后我可以整理其他帖子以确定最适合我的应用程序。

当然，如果这个问题没有确定的答案；告诉我，我会尝试从其他帖子中得出我自己的答案。

谢谢

================================================ =============

对所提供答案的更新回复

缓存和 Cookie 似乎是响应中的普遍偏好，但我也注意到缓存不是跨多个 Web 服务器使用的理想候选者的声明，因为同步可能是一个潜在问题。

感谢 Tim，据说数据库存储已经过优化，用户可以选择稍后返回并从上次中断的地方继续。

这是一个很好的观点，但要对概率保持远见；考虑到某些用户可能不会返回而在数据库中留下不必要的数据，这可能是合理的。

因此，保持数据库优化和清洁（“对我而言”具有同等相关性）需要实施维护任务，以根据设定的时间阈值自动使这些记录过期，以解决这些情况。虽然维护任务不是一个不容置疑的选择，但我仍然认为这只是为了作为临时存储的目的而为任务增加了一点工作。

尽管如此，我确实尊重蒂姆的建议，并相信在一定程度上反驳我最初的意见是值得的；数据库似乎不是存储临时数据的可行选择；所以我认为折衷方案是在结帐后将数据存储在数据库中（考虑到购物车或类似情况）。如您之前所述，通过这种方式，可以在后续访问时持续跟踪数据，以便您拥有交易记录。但更重要的是，将那些具有真正相关性的交易数据持久化到数据库中。

还有人说虽然Session比Database快；但尽管有一些警告，但在某种程度上可以通过其他机制（例如利用 SessionStateBehavior 属性）来缓解，这只是一个示例。

但是...我认为 Erik 有点用邓宁-克鲁格效应把观点带回家了。虽然，从这里给出的建议答案的内容和解释来看；我严重怀疑任何做出回应的人的专业知识是否值得怀疑。尽管如此，我倾向于同意获得一致意见这一事实可能比我的合理期望更高。

我更具体地寻找的是一种能够轻松适应多种场景的技术的普遍共识。换句话说，它不仅可以适应我的特定场景，还可以为具有潜在更重流量的更大环境提供可扩展性元素。这样一来，程序的变化要么完全缓解，要么至多是最小的。

================================================ ===

基于反馈的总结：

1. 会话变量似乎可以适应较小的案例场景并且在适用时，但它们有一些潜在的持久性问题以及其他值得注意的差异，正如 Erik 非常透彻地指出的那样。所以这个选项显然不适合可扩展的模型。

2. 缓存比会话变量更可取，但也不一定是“最佳”可扩展选项，因为除其他外，如前所述，Web 服务器场环境中潜在的同步复杂性。但仍然是一个选择。

3. 数据库存储是可扩展的，但出于临时易失性存储的目的，从数据库的角度来看，它可能不是最优雅的选择，因为它需要定期清理。就我个人而言，在我职业生涯的早期，我在数据库概念方面打下了坚实的基础，这可能不会是许多开发人员可能会同意的；但是从程序员的角度来看，为此目的使用数据库可能就足够了 Web 开发；但是从 DAL 和 DB 开发的角​​度来看，这（对我而言）有可能强制执行额外的 DB 任务来执行高效的后端。

4. Cookie 似乎是一个不错的选择，它结合了会话变量和缓存的“理想”元素。

================================================ ===

结论

根据答案；我认为，当事后需要持续的持久性时，COOKIES 和 CACHING 似乎是全面的建议，可以全面结合数据库存储的最佳实践；作为所提出的可扩展性的潜在良好候选者。

两者之间的最终选择似乎取决于需要存储的数据的数量和类型（例如敏感与非敏感，以及是否担心客户端可能会更改数据）；除了对 COOKIES 的特殊考虑之外，它们可能会被客户端禁用。

显然，没有一种适合所有解决方案的解决方案，正如从所提供的答案中明确指出和得出的结论，但在可扩展性方面；我可能错了，但这些似乎是最好的选择。

因为所有的反应都很好；我相当认为所有帖子都是有用的，并接受 Erik 的回答作为一个全面的整体可扩展解决方案。我希望我可以选择多个被接受的答案，因为我相信蒂姆的回答也非常简洁明了。

Gupta 的反应也很好，但我希望对提议的答案进行更详细的阐述，而不是重复以前的帖子。

谢谢各位！

Answer 1

不同预期的会话替代方案：-

当您在会话中保留某些内容时，它会破坏 ASP.NET MVC 中的主要规则。您可以使用这些选项来替代会话。

如果您的 asp.net (MVC) 会话对对象进行装箱拆箱，那么它会在服务器上产生一点负载。试试这个想法

1. 缓存：- 在会话中存储列表或类似大数据的东西更适合缓存。您可以控制它何时到期而不是用户会话。

2. 如果您的应用程序依赖于 JSON/Ajax 数据，那么您可以使用 html5 中提供的某种功能（如 WebSQL、IndexDB）。它不会使用 cookie，因此您可以在服务器上节省一些工作量。

Answer 2

什么时候

数据库经过高度优化。像购物车计数这样的简单值是数据库缓存的理想选择，并且（希望）便宜地直接计算。这可能不是问题。

但是，如果您排除了其他机制，则小的、逐用户的值是会话的可行候选者。

Cache 适用于站点范围的值或具有唯一键的用户特定值。但是，跨多个 Web 服务器同步缓存可能很困难。进程外会话状态将保持同步，因为它存储在单个位置（数据库或状态服务器）。

当然，有许多 3rd 方缓存替代方案，它们具有各种选项来保持同步。

无论计数临时存储在哪里，我认为购物车本身应该存储在数据库中，以便用户可以选择稍后返回并从他们离开的地方继续。

性能

如果您使用进程外会话状态（例如，在负载平衡环境中和/或使会话更持久），它会访问数据库或调用进程外服务，但是除非您要序列化大型对象图，否则调用相对便宜。

每个请求加载一次会话。后续读取访问速度非常快。

写入会话可能会损害性能，即使在没有负载的情况下也是如此。为什么？大多数现代应用程序使用异步调用，当多个异步调用命中读/写会话的 HTTP 处理程序（页面、控制器等）时，ASP.Net 将锁定会话以序列化访问。为了避免这种情况，你可以用[SessionState( SessionStateBehavior.ReadOnly )]装饰你的控制器

设计

现在我通过赋值成功完成了这个任务 到从我的 _layout 视图中检索到的 Session 变量；

这似乎是混合关注点，即让视图了解底层存储机制。从纯粹主义者的角度来看，我会在视图模型上设置这个值，或者至少把它放在ViewBag 中。从实际的角度来看，以这种方式检索到的一两​​个值可能不会造成任何伤害，但要注意不要让它进一步增长。

我在某处读到 MVC 过滤器与 Global.ascx 的结合使用 应用程序开始部分也是如此，但这似乎不合适 对于在控制器级别设置的变量，可能是静态的 变量。

静态变量具有完全合法的用途，但您必须彻底了解它们，否则可能会出现严重问题。

查看我关于 ASP.Net 中的静态变量的答案：

• does aspx provide special treatment for c# static variables
• Static fields vs Session variables

Answer 3

在任何一大群人中，你永远不会对任何事情达成一致意见。这只是人的本性。其中一部分源于Dunning-Kruger Effect，它指出人们对某个主题的了解越少，他们就越有可能高估自己在该主题上的专业知识。换句话说，很多人认为他们知道某事，但只是因为他们不知道他们不知道。部分原因只是人们有不同的经历，有些人在会话中没有发现问题，而有些人在各种情况下都有问题，反之亦然......

因此，为了支持您的研究，这表明答案在很大程度上取决于需求，我们需要了解您的需求是什么。如果这是一个高流量站点，在 Web 场中具有负载平衡的服务器，那么尽可能远离会话。当然，可以在服务器场环境中以各种方式共享会话（会话服务器、分布式缓存服务器等），但如果你能提供帮助，避免会话几乎总是更快。

如果您的网站是单台服务器，并且不太可能超出此范围。并且您的流量模式相对较低，那么会话可能是一个有用的选项。但是，您应该始终意识到会话是不可靠的存储，并且可能随时消失在您身上。如果应用程序池被回收，会话就消失了。如果未捕获的异常冒泡到工作进程，则会话可能会消失。如果 IIS 认为没有足够的内存，您的会话可能会消失，而不管配置了任何超时值。您也无法始终获得会话结束的可靠通知，因为终止的会话不会触发 Session_End 事件。

另一个问题是 Session 是序列化的。换句话说，IIS 一次阻止多个线程写入会话，并且它通常通过在线程运行时锁定会话来实现这一点，如果它没有选择退出可写会话锁定。在某些情况下，这可能会导致严重的问题，而在其他情况下只会导致性能不佳。如果您不打算在该方法中修改它，您可以通过使用只读会话属性标记各种方法来缓解这种情况。

最终，如果您确实选择使用会话，则尽可能仅将其用于小型、短暂的事情，如果不可能，则在会话丢失时构建一种“重新生成”数据的方式.例如，以购物车中的商品数量为例，您可以编写一个方法，首先检查该值是否存在，如果不存在，则将其从数据库中加载。始终使用此方法访问变量，而不是直接从会话中访问它...这样，如果会话丢失，它将重新加载它。

但是，话虽如此...对于购物车中的商品数量，我通常更喜欢使用 cookie 来获取此信息，因为 cookie 无论如何都会在每次加载时传递到页面，这是一个小的离散数据单位。通常更喜欢 Session 用于您希望阻止用户更改的敏感数据。购物车中的商品数量根本不符合该规则。