asp.net-mvc - MVC 中是否有最佳实践和推荐的 Session 变量替代方案

Question

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

但是，我可以说我(基于帖子)最终确定答案是基于要求的范围。但即使考虑到这一点，意见似乎也太多样化了，我无法决定我应该如何处理。

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

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

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

我读过的另一件事表明，如果站点上的流量很高，由于信息存储在服务器上， 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 应用程序启动部分，但这似乎不适合在 Controller 级别设置的变量以及静态变量。

有人可能会压制(因为没有更好的词)关于该主题的许多不同意见，并可能为该问题提供更明确的答案？我相信不同的意见都有其一席之地，我并不试图诋毁他们。但是有一个明确的、可能是一致的答案会更好；然后我可以对其他帖子进行分类，以确定最适合我的应用程序的内容。

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

谢谢

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

对所提供答案的更新回复

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

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

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

因此，保持数据库优化和清洁(“对我来说”同样重要)需要实现维护任务，以根据设定的时间阈值自动使这些记录过期，以解决这些情况。虽然维护任务不是一个毫无疑问的选择，但我仍然认为这只是为了作为临时存储的目的而为任务增加了更多的工作。

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

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

但是......我认为埃里克通过邓宁 - 克鲁格效应将这一点带回家。虽然，从这里给出的建议答案的内容和解释来看；我严重怀疑任何做出回应的人的专业知识是否有任何问题。尽管如此，我倾向于同意这样一个事实，即获得一致意见可能比我的合理预期要高一些。

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

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

根据反馈总结:

session 变量似乎适用于较小的案例场景，并且在适用时，但它们有一些潜在的持久性问题以及其他显着差异，正如 Erik 非常彻底地陈述的那样。所以这个选项显然不适合可扩展的模型。

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

数据库存储是可扩展的，但出于临时 volatile 存储的目的，从数据库的角度来看可能不是最优雅的选择，因为它需要定期清理。就我个人而言，在我职业生涯的早期拥有强大的数据库概念基础，这可能不会是许多开发人员可能会同意的；但从程序员的角度来看，为此目的使用数据库可能足以满足 Web 开发的需求；然而，从 DAL 和 DB 开发的角​​度来看，这(对我来说)有可能要求额外的 DB 任务来强制执行高效的后端。

Cookies 似乎是一个不错的选择，它结合了 session 变量和缓存的“理想”元素。

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

结论

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

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

显然，根据所提供的答案明确指出并得出结论，但在可扩展性方面，没有一种适用于所有情况的解决方案；我可能错了，但这些似乎是可用的最佳选择。

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

Gupta 的回应也很好，但我想要对提议的答案进行更多详细说明，而不是重复以前的帖子。

谢谢你们!

Answer 1

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

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

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

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

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

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