好的，首先，在任何人试图确定这是一个“重复”问题之前，请先进行；我已经审查了关于SO的大多数类似问题的文章，但即使综合考虑，我仍然对确定性还是有些困惑，或者也许我应该对此达成一致意见。
但是，我可以说（根据职位）我已经确定地答案是根据要求的范围。但是即使考虑到这一点，对于我来说似乎也有太多分歧，无法决定如何处理。
我的迫切要求是我需要在多个视图中持久保存来自1个控制器的变量数据。更具体地说，我有一个控制器和一个对应的视图来处理购物车中的物品计数，我想将该数据持久保存在多个视图中。我认为_layout视图是最合理的选择。
现在，通过将值分配给从我的_layout视图检索的Session变量，我已经成功完成了此任务；因此，即使用户要浏览网站中的任何位置，购物车中的商品数量也将持续存在，直到他们离开网站或完成结帐；在这种情况下，变量将在代码中清除。
我读过的帖子似乎偏向于要么不使用Session变量而是使用Cookie，要么将数据存储在数据库中。或说明出于我打算使用它们的意图，Session变量非常适合使用。
我读过的另一件事表明，如果网站上的流量很高，则会话变量可能会阻碍整体性能，因为信息存储在服务器上。
我个人无法证明将这种类型的信息存储在数据库中并随后访问该数据库是合理的，因为我认为这也会影响站点性能，并且对于临时数据的存储似乎有些过大。TempData，ViewData和ViewBag在持久保存数据时不起作用，因此它们不是IMO要求的逻辑选择。
如果还有另一个非常适合的Session变量替代方法（对我有用），我想知道它是什么。
2个帖子在提供最佳建议方面似乎相互矛盾，这让我有些困惑。
缺点：避免在ASP.NET MVC中使用会话状态是一种好习惯吗？如果是，原因和方式是什么？
优点：仍然可以在ASP.NET mvc中使用Session变量，或者对于某些事情（例如购物车）是否有更好的选择
似乎这个问题（尽管有许多不同的变体）没有我可以得出的明确答案。
如果有一种更可取的方式来实现这一目标而又不过分，那么这就是我所要寻找的答案。
我还与Global.ascx应用程序开始部分一并阅读了MVC过滤器的用法，但这似乎不适用于控制器级别设置的变量，甚至不适合于静态变量。
有人可以压扁（因为缺少一个更好的词）关于该主题的许多不同意见，也许可以为这个问题提供更明确的答案？我敢肯定，各种意见都有其应有的地位，并且我不会试图抹黑它们。但是有一个确定的，可能是一致的答案会更好。然后我可以对其他帖子进行排序，以确定最适合我的应用程序的内容。
当然，如果这个问题没有明确的答案；告诉我，我将尝试从其他帖子中得出自己的答案。
谢谢
================================================== =========
缓存和Cookies似乎是响应中的普遍偏好，但是我也注意到了这样的说法：缓存不是在多个Web服务器上使用的理想选择，因为同步可能是一个潜在的问题。
值得称赞的是，Tim表示数据库存储已得到优化，用户可以选择稍后再返回，并从中断的地方继续。
这是一个很好的观点，但要对概率保持先见之明。考虑到某些用户可能不会返回而将不必要的数据留在数据库中，因此这可能是合理的。
因此，保持数据库的优化和整洁（“对我而言”是同等重要的）将需要实施维护任务，以根据设置的时间阈值自动过期那些记录，以解决这些情况。尽管维护任务并非是毫无疑问的选择，但我仍然认为，仅出于用作临时存储的目的，这会使任务增加了更多工作。
尽管如此，我还是尊重蒂姆的建议，并认为在一定程度上反驳我的初衷是值得的。数据库似乎不是存储临时数据的可行选择；因此，我认为折衷方案可能是在结帐后将数据存储在数据库中（考虑到购物车或类似情况）。如您先前所述，可以在以后的访问中持续跟踪数据，因此您有交易记录。但更重要的是，那些与交易真正相关的数据才能持久保存到数据库中。
还有人说，尽管会话比数据库快；但尽管有一些警告可以通过其他机制（例如利用SessionStateBehavior属性）在某种程度上减轻，但这只是一个示例。
但是...我认为Erik凭借Dunning-Kruger效应推动了这一点。尽管从这里给出的建议答案的内容和解释来看；我严重怀疑已做出回应的任何人的专业知识是否会受到质疑。尽管如此，我倾向于同意获得一致意见这一事实可能比我的合理预期要高。
我更特别地希望找到一种可以轻松适应各种场景的技术的普遍共识。换句话说，不仅可以适应我的特定情况，而且还可以为具有较大流量的较大环境提供可伸缩性。这样一来，编程的变化将完全被缓解，或者最大程度地减少。
==================================================
会话变量似乎可以适应较小的情况，并且在适用时也适用，但正如Erik所周知的那样，它们在持久性方面还有其他一些明显的差异。因此，此选项显然不适合可伸缩模型。
与会话变量相比，缓存是更可取的，但由于前面提到的Web服务器场环境中潜在的同步复杂性，缓存仍然不是“最佳”可伸缩选项。但是还是有选择的。
数据库存储具有可伸缩性，但出于临时目的，从数据库角度来看，临时易失性存储可能不是最理想的选择，因为它需要定期清理。就个人而言，在我职业生涯的早期就拥有数据库概念的坚实基础，这可能不会被许多开发人员所认同。但是从程序员的角度来看，为此目的使用数据库可能就足够了。但是，从DAL和数据库开发的角度来看（对我而言），这有可能要求执行额外的数据库任务来实施高效的后端。
Cookies似乎是结合Session变量和缓存的“理想”元素的不错选择。
==================================================
根据答案；我认为，COOKIES和CACHING似乎是全面综合最佳实践的全面建议，并且在事后需要持续持久性的情况下，还建议使用数据库存储。作为所介绍产品可扩展性的潜在好候选者。
在这两者之间的最终选择似乎取决于需要存储的数据的数量和类型（例如，敏感数据与非敏感数据，以及是否担心客户端可能会在其端更改数据）；除了对COOKIES的特殊考虑之外，客户可能会禁用它们。
显然，从提供的答案中可以清楚地指出和得出结论，没有一种适合所有解决方案的规模，而是在可扩展性方面。我可能是错的，但这些似乎是最好的选择。
因为所有的回应都很好；我想将所有帖子都归功于有用，并将接受Erik的回答作为全面完善的整体可扩展解决方案。我希望我可以选择多个答案，因为我相信蒂姆的回答也很简洁明了。
古普塔的回应也不错，但我想对拟议的答案做更多的阐述，而不是重复以前的帖子。
多谢你们！
您将永远不会对任何一大群人的任何事情获得一致的意见。那只是人的本性。其中的部分原因是邓宁-克鲁格效应（Dunning-Kruger Effect），该效应指出，某人对某个主题的了解越少，他们就越有可能过高地评估自己在该主题上的专业知识。换句话说，很多人认为他们知道某些东西，但这仅仅是因为他们不知道自己不知道。部分原因是人们有不同的经历，有些人发现会话没有问题，而另一些人则处于各种情况下，反之亦然。
因此，要备份您的研究（这表明答案很大程度上取决于要求），我们需要了解您的要求是什么。如果这将是一个高流量站点，并且在Web场中具有负载平衡的服务器，则应尽可能远离会话。当然，可以在服务器场环境（会话服务器，分布式缓存服务器等）中以各种方式共享会话，但是如果可以帮助的话，避免会话几乎总是更快。
如果您的站点是一台服务器，并且不可能超过该服务器。而且您的流量模式相对较低，那么会话可能是一个有用的选择。但是，您应该始终意识到会话是不可靠的存储，并且随时都可能消失。如果应用程序池被回收，会话将消失。如果未捕获的异常在工作进程中冒泡，则该会话可能会消失。如果IIS认为没有足够的内存，则无论配置了什么超时值，会话都可能消失。由于终止的会话不会触发Session_End事件，因此您也无法始终获得会话已结束的可靠通知。
另一个问题是会话已序列化。换句话说，IIS阻止一次有多个线程写入会话，并且它通常通过在线程运行时锁定会话（如果它没有选择退出可写会话锁定）来锁定会话。在某些情况下，这可能导致严重的问题，而在其他情况下，则可能导致性能下降。如果您不想在该方法中进行修改，则可以通过使用只读会话属性标记各种方法来缓解这种情况。
最终，如果您确实选择使用会话，则尽可能尝试仅将其用于较小的，短暂的事物；如果不可能，则以一种方式来构建它以在会话丢失时“重新生成”数据。例如，使用购物车中的物品数量示例，您可以编写一个方法，该方法首先检查该值是否存在，如果不存在，则该值会从数据库中加载。始终使用此方法访问变量，而不是直接从会话中访问变量...这样，如果会话丢失，它将重新加载它。
不过，话虽如此...对于购物车中的物品数量，我通常更喜欢使用cookie来获取此信息，因为无论如何，每次加载时cookie都会传递到页面，这是一个小的离散数据单元。通常，您希望使用Session来获取敏感数据，以防止用户更改数据。购物车中的物品数量根本不符合该规则。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句