我正在使用AcceptVerbsScott Gu 的 Preview 5 博客文章中详述的方法来处理 ASP.NET MVC 中的表单条目：
所以我不必使用TempData. 也就是说，我现在必须在此过程中添加一个“确认”步骤，并且似乎需要使用TempData.
出于某种原因，我讨厌使用TempData它——它是围绕它设计的东西。
这是一个有效的担忧，还是我在编造？
无需厌恶 TempData... 但如果使用不当，它肯定表明设计不佳。如果您使用的是 RESTful URL，则 TempData 是将消息从 POST 操作传输到 GET 操作的最佳实践。考虑一下：
您在 URL Products/New 有一个表格。表单发布到 Products/Create，它验证表单并创建产品，成功时控制器重定向到 URL Products/1，错误时将重定向回 products/New 以显示错误消息。
Products/1 只是产品的标准 GET 操作，但我们希望显示一条消息，指示插入成功。TempData 非常适合这个。将消息添加到 Post Controller 中的 TempData 并在视图中添加一些 if 逻辑并完成。
失败时，我一直在将 formCollection 中输入的值和错误消息集合添加到 Post Action 中的 TempData，并重定向到初始 Action Prodcuts/New。我在视图中添加了逻辑，以使用先前输入的值以及任何错误消息填充表单输入。对我来说似乎又好又干净！
我认为您最好在使用 TempData 之前犹豫一下。TempData 存储在会话中，如果出现以下情况，这可能会对您产生影响：
如果您的站点需要具有高可用性，那么围绕应用会话状态还有其他注意事项，但这些都是可以解决的问题。
我有点认为临时数据是一种通知用户的即发即弃机制。让他们想起他们最近所做的事情真是太好了，但我也会犹豫是否将其作为某些用户流程中的必需步骤。原因是如果他们刷新页面，我相信它会消失。好吧，我想我也不愿意使用它，因为它并没有很好地定义它的可靠性。
我想知道问题是否在于您在确认步骤之前将操作重定向到另一个页面。我想知道在他们第一次提交之后，您是否可以进行足够的处理来生成确认对话框，然后返回带有确认问题的原始页面。与您进行验证的方式类似，除了验证规则检查是否执行了确认步骤（在其他验证通过之前隐藏确认 UI）。
我有一个 GetModel 方法，它首先检查 TempData["model"] 并返回它。否则 GetModel 从数据库加载适当的数据。
当我有一个需要返回需要相同模型数据的不同视图的操作时，它可以节省数据库的额外负载。
查看MVC3 中的无会话控制器。事实证明，使用 session 会阻止并行执行单个用户的请求，从而导致性能下降。
由于 tempdata 默认使用会话，因此您将无法使用此功能。您可以切换到对临时数据使用 cookie，但这有点尴尬（至少对我而言）。不过，仍然比 viewstate 更干净，所以也许它不是什么大问题。
这就像使用 ViewData，这意味着它可能没有安全风险。但我宁愿使用 ViewData 而不是 TempData。在这里查看比较：http ://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/
根据设计，您始终可以将用户/购物篮或您需要的任何内容存储在数据库中的临时数据中，并且只有一个“IsReady”字段来指示它是否已完成，如果您想在以后使用它可以扩展它请注意，人们可以关闭浏览器。
为什么会有这样的反感？这件事就是做好它的工作并让它做好:)
如果你不喜欢它，因为它是非强类型的，你总是可以制作一个包装器，为你提供强类型接口。
所有好的答案，你有没有看过这个来传递消息。
TempData 和 Session 并不是 RESTful 架构的最佳选择，因为大多数会话都存储在内存中。因此，当您想使用服务器场时，用户会话将存在于一台服务器上，而他们的下一个请求可能会发送到另一台服务器。
话虽这么说，请在此处查看使用 TempData 传递消息。
http://jameschambers.com/2014/06/day-14-bootstrap-alerts-and-mvc-framework-tempdata/
如果仅用于重定向到另一个页面警报，则可以调整以使用查询字符串方法。