但我可以说，我(基于职位)最终确定答案是基于要求的范围。但是，即使考虑到这一点，我的意见似乎太多样化，以决定如何处理这一点。
我的直接要求是，我需要在多个视图中保留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?
看来这个问题(虽然以许多不同的变化呈现)没有确定的答案，我可以总结。
如果有一个更喜欢的方法来完成这个没有overkill那就是我正在寻找的答案。
我读某处使用MVC过滤器与Global.ascx应用程序启动部分，但是这似乎不适合在控制器级别设置的变量尽可能多的静态变量。
有人可能挤压(因为缺乏一个更好的词)关于这个话题的许多不同的意见，并可能提供一个更确定的回答这个问题？我相信不同的意见有他们的地方，我不是试图抹黑他们。但有一个明确的，可能一致的答案会更好;然后我可以通过其他职位，以确定什么是最适合我的应用程序。
当然，如果这个问题没有确定的答案;只是告诉我，我会尝试从其他职位派生我自己的答案。
谢谢
================================================== =========
对答案的更新反应
缓存和Cookie似乎是响应的一般偏好，但我也注意到缓存它不是一个理想的候选人使用跨多个Web服务器的声明，因为同步可能是一个潜在的问题。
给予Tim的信用，它表示数据库存储已优化，用户可以选择以后返回，继续他们离开的地方。
这是一个很好的点，但要保持对概率的预见;它可能是合理的，一些用户可能不会返回在数据库中留下不必要的数据。
因此，保持数据库优化和清理(“对我”具有相同的相关性)将需要实施维护任务，以基于设定的时间阈值自动使这些记录过期，以解决这些情况。虽然维护任务不是一个毫无疑问的选项，但我仍然认为这只是为了作为临时存储的意图目的仅仅为该任务增加了一些工作。
尽管如此，我仍尊重蒂姆的建议，并相信它应该在某种程度上反对我的初步意见;数据库似乎不是存储临时数据的可行选项;所以我认为妥协将数据存储在数据库(给定的购物车或类似的场景)，可能在结账后。这样，如前所述，数据可能会在后续访问时持续跟踪，因此您有交易记录。但更重要的是，这些事务的数据具有真正的相关性，以坚持到数据库。
还有人说，虽然Session比数据库快;但是尽管它的注意力在某种程度上可以通过其他机制来减轻，例如利用SessionStateBehavior属性，仅仅作为一个示例。
但是我想埃里克的种种驱动点回家与催款克鲁格效应。虽然，从这里给出的建议答案的内容和解释;我严重怀疑任何回答的人的专业知识是任何方式有问题。然而，我倾向于同意获得一致意见的事实可能有点高于我的合理期望。
我更具体地寻找一个一般的共识，一种技术，将舒适地适应各种各样的情况。换句话说，将不仅适应我的特定场景，而且还向具有可能更重的业务的较大环境提供可扩展性的元素。这样，编程中的改变将被完全减轻或者最小化。
==================================================
基于反馈的总结：
>会话变量似乎适应较小的情况下和适用时，但他们有一些潜在的持久性关注的其他显着的差异，如Erik所说。所以这个选项显然不适合可扩展的模型。
>缓存优于会话变量，但是由于除了其他因素之外，还优选地不是必需的“最佳”可扩展选项，如之前所指出的，web服务器场环境中的潜在的同步复杂性。但是一个选择。
>数据库存储是可扩展的，但是出于意图目的，临时易失性存储可能不是数据库视图中最优雅的选项，因为它需要定期清理。就个人而言，在我的职业生涯早期，在数据库概念中有一个坚实的基础，这可能不会是许多开发人员可能同意的东西;但是为此目的使用数据库可能足以从程序员的角度看Web开发;然而从DAL和DB开发的角度来看，这(对我)有可能强制执行一个额外的数据库任务来实施一个高效的后端。
> Cookie似乎是一个不错的选项，具有会话变量和缓存的组合“可取”元素。
==================================================
结论
基于答案;我认为COOKIES和CACHING似乎是一个很好的全面的最佳实践的建议，结合数据库存储，在事后需要持续持续时;作为所提出的可扩展性的潜在好的候选者。
2之间的最终选择似乎是基于需要存储的数据的量和类型(例如敏感对非敏感数据以及客户端是否可能改变其末端的数据);除了COOKIES的特殊考虑事实，他们可能被客户禁用。
显然，没有一个尺寸适合所有解决方案，从提供的答案清楚地指出和结论，但在可扩展性;我可能错了，但这似乎是最好的选择。
因为所有的反应都很好;我公平地将所有的帖子归功于有用，并接受Erik的答案作为一个全面的整体可扩展的解决方案。我希望我可以选择多个接受的答案，因为我相信蒂姆的回答也很好地列出和简洁。
Gupta的反应也很好，但我想要更详细的提出的答案，而不是以前的职位的重复。
多谢你们！
解决方法
因此，要备份您的研究，这表明答案在很大程度上取决于要求，我们需要了解您的要求。如果这是一个高流量站点，在Web场中负载平衡的服务器，则尽可能远离会话。当然，可以在服务器场环境(会话服务器，分布缓存服务器等)以各种方式共享会话，但是避免会话几乎总是更快，如果你可以帮助它。
如果你的网站是一个单一的服务器，并且不可能超越这一点。您的流量模式相对较低，那么会话可能是一个有用的选项。但是，您应该始终注意会话是不可靠的存储，并且可以随时消失。如果应用程序池被回收，会话就会消失。如果未捕获的异常冒泡到工作进程，那么会话可能会消失。如果IIS认为没有足够的内存，您的会话可能会失效，无论配置任何超时值。您也不能总是获得会话已结束的可靠通知，因为已终止的会话不会触发Session_End事件。
另一个问题是Session被序列化。换句话说，IIS阻止多个线程一次写入会话，并且它通常通过在线程运行时锁定会话(如果它没有选择退出可写会话锁定)。这在一些情况下可能导致严重的问题，并且在其他情况下仅仅是差的性能。您可以通过使用只读会话属性标记各种方法来缓解这种情况，如果您不打算在该方法中修改它。
最终，如果你确实选择使用会话，那么尽量只使用它来处理小的，短暂的事情，如果不可能的话，如果不可能，那么建立一个方法来“重新生成”数据，如果会话丢失。例如，在购物车示例中使用您的商品数量，您可以编写一个方法，首先检查值是否存在，如果不存在，则退出并从数据库加载它。总是使用这种方法来访问变量，而不是直接从会话访问…这种方式，如果会话丢失，它只会重新加载它。
但是，说了这个…对于购物车中的项目数量，我通常喜欢使用cookie的信息，因为cookie传递到页面上的每个负载，无论如何，这是一个小的离散数据单元。通常偏好敏感数据的会话，您想要阻止用户能够更改..购物车中的项目数量根本不适合该规则。
