ASP.NET MVC - TempData - 好的或坏的做法答案

【问题标题】：ASP.NET MVC - TempData - Good or bad practiceASP.NET MVC - TempData - 好的或坏的做法
【发布时间】：2008-12-22 16:30:13
【问题描述】：

我正在使用 Scott Gu 的 Preview 5 博客文章中详述的 AcceptVerbs 方法来处理 ASP.NET MVC 中的表单条目：

用户通过 GET 获取一个空表单
用户通过 POST 将填写的表单发布到同一个 Action
Action 验证数据、采取适当的操作并重定向到新视图

所以我不必使用TempData。也就是说，我现在必须在此过程中添加一个“确认”步骤，并且似乎需要使用TempData。

出于某种原因，我不喜欢使用TempData——因为它是围绕它设计的东西。

这是一个合理的担忧，还是我在编造？

【问题讨论】：

考虑让您的“确认”步骤成为一个 JavaScript 对话框。减少服务器往返次数，您就不会遇到这个问题。

标签： asp.net-mvc tempdata

【解决方案1】：

不需要对 TempData 产生反感...但是如果使用不当，它肯定是设计不佳的迹象。如果您使用的是 RESTful URL，则 TempData 是将消息从 POST 操作传输到 GET 操作的最佳实践。考虑一下：

您在 URL Products/New 有一个表单。表单 Posts to Products/Create，验证表单并创建产品，成功时控制器重定向到 URL Products/1，出错时将重定向回 products/New 以显示错误消息。

Products/1 只是产品的标准 GET 操作，但我们希望显示一条消息，指示插入成功。 TempData 非常适合这个。将消息添加到 Post Controller 中的 TempData 并在视图中添加一些 if 逻辑并完成。

失败时，我一直在将 formCollection 中输入的值和错误消息集合添加到 Post Action 中的 TempData，并重定向到初始 Action Prodcuts/New。我在视图中添加了逻辑，以使用先前输入的值以及任何错误消息填充表单输入。对我来说似乎又好又干净！

【讨论】：

当您可以直接回帖到Products/New 时，为什么还要额外工作？ Products/Create 加了什么值？
@Mark，使用 Products/Create 可以防止用户通过回发完成操作，然后在稍后刷新（或书签和返回）时意外重新完成操作的情况。有关更多信息，请参阅en.wikipedia.org/wiki/Post/Redirect/Get
@ehdv：但真的如此吗？成功时它会重定向到另一个页面，失败时它应该显示表单错误并且不应该采取任何措施，因此不会造成任何伤害。它只会阻止烦人的“您确定要重新发布”消息，而我经常想要这样做。我想这取决于你的设计，所以我明白你的意思。

【解决方案2】：

我认为您最好在使用 TempData 之前犹豫一下。 TempData 存储在会话中，如果出现以下情况，这可能会对您产生影响：

您现在没有在您的网站上使用会话
您的系统需要扩展到高吞吐量，即您希望完全避免会话状态
您不想使用 cookie（我不知道 MVC 现在对无 cookie 会话的支持情况如何）

如果您的网站需要高可用性，那么在应用会话状态方面还有其他注意事项，但这些都是可以解决的问题。

【讨论】：

TempData 不必存储在会话中，尽管它是默认提供程序 - 这可能是它不在方法文档中的原因。还有一个 cookie 提供程序，作为如何编写自定义提供程序的示例。

【解决方案3】：

我认为临时数据是一种通知用户的即发即弃机制。很高兴提醒他们他们最近所做的事情，但我也会犹豫是否将其作为某些用户流程中的必要步骤。原因是如果他们刷新页面，我相信它会消失。好吧，我想我也很犹豫是否要使用它，因为它并没有很好地定义它的可靠性。

我想知道问题是否在于您在确认步骤之前将操作重定向到另一个页面。我想知道在他们第一次提交之后，您是否可以进行足够的处理来生成确认对话框，然后返回带有确认问题的原始页面。类似于您可能进行的验证，除了验证规则检查是否执行了确认步骤（确认 UI 隐藏，直到其他验证通过）。

【讨论】：

【解决方案4】：

我有一个 GetModel 方法，它首先检查 TempData["model"] 并返回它。否则 GetModel 从数据库中加载适当的数据。

当我有一个操作需要返回需要相同模型数据的不同视图时，它可以节省数据库的额外负载。

【讨论】：

是的，我遇到了这个问题：（1）验证记录是否存在，如果有效，则重定向到页面（2）加载记录以显示给用户。因此，数据库被点击以进行验证和显示。我几乎为此使用了 TempData，但我想检查意见。我喜欢你的方法来包含它。
在这种情况下最好使用适当的缓存机制。

【解决方案5】：

在 MVC3 中查看 sessionless controllers。事实证明，使用 session 会阻止并行执行单个用户的请求，从而导致性能下降。

由于 tempdata 默认使用会话，因此您将无法使用此功能。您可以切换到对临时数据使用 cookie，但这有点尴尬（至少对我而言）。不过，仍然比 viewstate 更干净，所以也许它不是什么大问题。

【讨论】：

您对无会话控制器和 TempData 使用会话是正确的。可是等等！ Session 不是一件坏事，您可以将 Sessionless 与 Session 控制器混合搭配。当您（从浏览器）对服务器进行大量 AJAX 调用时，您确实需要 Session_less_ 控制器。当您一次只点击一页时- ..您不需要无会话。事实上，这不应该给你带来任何好处......因为你只打服务器一次。所以可以混搭。

【解决方案6】：

你为什么会有这样的反感？这件事就是做好它的工作，把它做好:)

如果你不喜欢它，因为它是非强类型的，你可以随时制作一个包装器，为你提供强类型接口。

【讨论】：

【解决方案7】：

这就像使用 ViewData，这意味着它可能没有安全风险。但我宁愿使用 ViewData 而不是 TempData。在这里查看比较：http://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/

根据设计，您始终可以将用户/购物篮或您需要的任何内容存储在数据库中的临时数据中，并且只有一个“IsReady”字段来指示它是否已完成，如果您需要，它可以在以后进行扩展请记住，人们可以关闭浏览器。

【讨论】：

注意：您链接到的文章在当时是最新的，但仅适用于 MVC1。 TempData 在 MVC2 中发生了相当大的变化。
@mikemann，是的。但答案是从 2008 年底开始的。但也许应该更新答案？

【解决方案8】：

所有好的答案，你有没有看过这个来传递消息。

TempData 和 Session 并不是 RESTful 架构的最佳选择，因为大多数会话都存储在内存中。因此，当您想使用服务器场时，用户会话将存在于一台服务器上，而他们的下一个请求可能会发送到另一台服务器。

话虽如此，请看看这里使用 TempData 传递消息。

http://jameschambers.com/2014/06/day-14-bootstrap-alerts-and-mvc-framework-tempdata/

如果仅用于重定向到另一个页面警报，则可以调整为使用查询字符串方法。

【讨论】：