asp.net-mvc – 有一个最佳实践和建议替代会话变量在MVC

好吧，所以首先，任何人试图确定这是一个“重复”的问题;我已经审查了大多数关于类似问题SO的职位，但即使结合所有的一切，我仍然有点处于一个困境的确定性，或者我应该说一致同意这一点。

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

我的直接要求是，我需要在多个视图中保留1个控制器的可变数据。更具体地说，我有一个控制器和相应的视图来处理购物车项目计数，我想在多个视图中持久化数据。我认为_layout视图是最合理的选择。

现在我已经成功地完成了这个任务通过分配值到一个会话变量，从我的_layout视图检索;因此即使用户在网站内的任何地方进行导航，购物车中的商品数量也会持续，直到他们离开网站或完成结帐;在这种情况下，变量将在代码中清除。

我读过的帖子似乎偏向于保持远离会话变量，赞成Cookie和在数据库中存储数据;或者说，为了我提议使用它们的意图目的，会话变量完全可以使用。

另一件我读过的建议，如果在网站上有高流量的会话变量可能会妨碍整体性能，因为信息存储在服务器上。

我个人不能证明将这种类型的信息存储在数据库中，然后击中数据库，因为我想，这也可能会影响网站的性能，似乎有点过分的存储临时数据。 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)

看来这个问题(虽然以许多不同的变化呈现)没有确定的答案，我可以总结。

如果有一个更喜欢的方法来完成这个没有overkill那就是我正在寻找的答案。

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

有人可能挤压(因为缺乏一个更好的词)关于这个话题的许多不同的意见，并可能提供一个更确定的回答这个问题？我相信不同的意见有他们的地方，我不是试图抹黑他们。但有一个明确的，可能一致的答案会更好;然后我可以通过其他职位，以确定什么是最适合我的应用程序。

当然，如果这个问题没有确定的答案;只是告诉我，我会尝试从其他职位派生我自己的答案。

谢谢

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

对答案的更新反应

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

给予Tim的信用，它表示数据库存储已优化，用户可以选择以后返回，继续他们离开的地方。

这是一个很好的点，但要保持对概率的预见;它可能是合理的，一些用户可能不会返回在数据库中留下不必要的数据。

因此，保持数据库优化和清理(“对我”具有相同的相关性)将需要实施维护任务，以基于设定的时间阈值自动使这些记录过期，以解决这些情况。虽然维护任务不是一个毫无疑问的选项，但我仍然认为这只是为了作为临时存储的意图目的仅仅为该任务增加了一些工作。

尽管如此，我仍尊重蒂姆的建议，并相信它应该在某种程度上反对我的初步意见;数据库似乎不是存储临时数据的可行选项;所以我认为妥协将数据存储在数据库(给定的购物车或类似的场景)，可能在结账后。这样，如前所述，数据可能会在后续访问时持续跟踪，因此您有交易记录。但更重要的是，这些事务的数据具有真正的相关性，以坚持到数据库。

还有人说，虽然Session比数据库快;但是尽管它的注意力在某种程度上可以通过其他机制来减轻，例如利用SessionStateBehavior属性，仅仅作为一个示例。

但是我想埃里克的种种驱动点回家与催款克鲁格效应。虽然，从这里给出的建议答案的内容和解释;我严重怀疑任何回答的人的专业知识是任何方式有问题。然而，我倾向于同意获得一致意见的事实可能有点高于我的合理期望。

我更具体地寻找一个一般的共识，一种技术，将舒适地适应各种各样的情况。换句话说，将不仅适应我的特定场景，而且还向具有可能更重的业务的较大环境提供可扩展性的元素。这样，编程中的改变将被完全减轻或者最小化。

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

基于反馈的总结：

>会话变量似乎适应较小的情况下和适用时，但他们有一些潜在的持久性关注的其他显着的差异，如Erik所说。所以这个选项显然不适合可扩展的模型。
>缓存优于会话变量，但是由于除了其他因素之外，还优选地不是必需的“最佳”可扩展选项，如之前所指出的，web服务器场环境中的潜在的同步复杂性。但是一个选择。
>数据库存储是可扩展的，但是出于意图目的，临时易失性存储可能不是数据库视图中最优雅的选项，因为它需要定期清理。就个人而言，在我的职业生涯早期，在数据库概念中有一个坚实的基础，这可能不会是许多开发人员可能同意的东西;但是为此目的使用数据库可能足以从程序员的角度看Web开发;然而从DAL和DB开发的角度来看，这(对我)有可能强制执行一个额外的数据库任务来实施一个高效的后端。
> Cookie似乎是一个不错的选项，具有会话变量和缓存的组合“可取”元素。

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

结论

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

2之间的最终选择似乎是基于需要存储的数据的量和类型(例如敏感对非敏感数据以及客户端是否可能改变其末端的数据);除了COOKIES的特殊考虑事实，他们可能被客户禁用。

显然，没有一个尺寸适合所有解决方案，从提供的答案清楚地指出和结论，但在可扩展性;我可能错了，但这似乎是最好的选择。

因为所有的反应都很好;我公平地将所有的帖子归功于有用，并接受Erik的答案作为一个全面的整体可扩展的解决方案。我希望我可以选择多个接受的答案，因为我相信蒂姆的回答也很好地列出和简洁。

Gupta的反应也很好，但我想要更详细的提出的答案，而不是以前的职位的重复。

多谢你们！