TempData的实施改变 - 改变的原因 [英] TempData implementation changes - Reasons for the change

问题描述

在ASP.NET MVC 2，在 TempDataDictionary 是只是一个HTTP请求的条目的寿命。

In ASP.NET MVC 2, the lifespan of an entry in the TempDataDictionary was just one HTTP Request.

这翻译成在一个请求中设置的值，重新定向，并具有在线路的另一端连接到相同的项目。在此之后，条目将不再可用，无论你在该行的末后读出值的字典还是不行。

That translated to setting a value in one request, redirecting, and having access to the same item at the other end of the line. After this the entry would be no longer available, regardless of whether you read the value out of the dictionary at the latter end of the line or not.

由于ASP.NET MVC 3（我相信），该实施细节都相当显著的变化。

Since ASP.NET MVC 3 (I believe), this implementation detail has changed quite significantly.

在条目的 TempDataDictionary 一旦被读取的现在只删除。

Entries in the TempDataDictionary are now only removed once they've been read.

MVC 4

public object this[string key]
    {
      get
      {
        object obj;
        if (!this.TryGetValue(key, out obj))
          return (object) null;
        this._initialKeys.Remove(key);
        return obj;
      }
    }

和

public bool TryGetValue(string key, out object value)
    {
      this._initialKeys.Remove(key);
      return this._data.TryGetValue(key, out value);
    }

MVC 2：

public object this[string key] {
            get {
                object value;
                if (TryGetValue(key, out value)) {
                    return value;
                }
                return null;
            }

和

public bool TryGetValue(string key, out object value) {
            return _data.TryGetValue(key, out value);
        }

由于大多数人似乎把的TempData 集合中的项目在一个请求，并立即读取他们在不久的下一个请求退了出去，功能似乎roughtly相同。

Since most people seem to put items in the TempData collection in one request and immediately read them back out in the immediate next request, the functionality seems roughtly the same.

在场景中不是这种情况下，如想如果重定向到一个地方读的TempData 项，并期待它已被删除，如果请求其他资源和导航回来，这种变化具有相当的影响。

In scenarios where this is not the case such as wanting to read the TempData entry if redirected to one place, and expecting it to have been removed if requesting other resources and navigating back, this change has quite an impact.

不再是一个HTTP请求的可用条目，但可以在很多的HTTP请求，无论是只适用于单一得到的字典。

No longer is the entry available for one http request but is available over many HTTP requests, be it only available to one single get on the dictionary.

我想知道更多关于这个执行力度的变化，什么是对变化的原因，是这仅仅是为了满足多重定向，还是有更深层次的好处？

I'd like to know more about this implimentation change, what were the reasons for the change, was this simply to cater for multiple redirects or are there deeper benefits?

继发于这一点，我很好奇知道如果有什么内置的，现在迎合数据的同样的方式，使用的TempData ，以满足一个HTTP请求共享呢？

Secondary to that, I'm intrigued to know if there's anything built in that now caters for single HTTP request sharing of data in the same way that TempData used to cater for?

推荐答案

您是否已经阅读（或之后的是正确的，的TempData 键才会被清除用户的会话过期），但是这一直以来MVC2的情况下，（ http://forums.asp.net /post/3692286.aspx ）

You're correct that TempData keys are only cleared if they’ve been read (or after the user’s session expires) but this has been the case since MVC2, (http://forums.asp.net/post/3692286.aspx)

我想知道更多关于这个执行力度的变化，请问是什么
  变化的原因，是这仅仅是为了满足多
  重定向还是有更深层次的好处？

I'd like to know more about this implimentation change, what were the reasons for the change, was this simply to cater for multiple redirects or are there deeper benefits?

这改变prevented，在MVC 1出现的问题，如的TempData 他们被读取之前被删除键。所以，是的，主要的好处是避免这些问题，当你有多个重新定向，或交错的请求。此外， RedirectToRouteResult 或 RedirectResult 方法现在自动调用 TempData.Keep（）来钥匙prevent结算，他们已经读即使如此记住这一点为好。

This change prevented problems that arose in MVC 1, such as TempData keys being deleted before they were read. So yes, the primary benefit is in avoiding these problems when you have multiple re-directs, or interleaved requests. In addition, the RedirectToRouteResult or RedirectResult methods now automatically call TempData.Keep() to prevent clearing of keys, even after they've been read so keep that in mind as well.

在场景中不是这种情况下，如想读
  TempData的条目;如果不重新定向到一个地方，并期待它有
  如果请求其他资源和导航回被删除，这
  变化有相当的影响。

In scenarios where this is not the case such as wanting to read the TempData entry if redirected to one place, and expecting it to have been removed if requesting other resources and navigating back, this change has quite an impact.

你是正确的，如果你已经假定的TempData 键自动清除你可能会遇到意想不到的问题下的编码。您可以拨打 TempData.Clear（）来手动删除所有键 TempDataDictionary 或 TempData.Remove（键）删除特定键。您还可以使用 TempData.Peek（）读的TempData 键的值毫不气馁它从去除 TempDataDictionary 。

You’re correct, if you've been coding under the assumption that the TempData keys are cleared automatically you could run into unexpected problems. You can call TempData.Clear() to manually remove all keys from the TempDataDictionary, or TempData.Remove(key) to remove a specific key. You can also use TempData.Peek() to read the value of a TempData key without flagging it for removal from the TempDataDictionary.

继发于是，我好奇知道是否有建于什么
  现在迎合在同一数据的单个HTTP请求共享
  方式TempData的用于满足？

Secondary to that, I'm intrigued to know if there's anything built in that now caters for single HTTP request sharing of data in the same way that TempData used to cater for?

我不知道复制原来实行的TempData的任何新对象或功能。本质上讲，我们仍然使用的TempData ，但必须铭记，该数据一直保持到阅读和手工清除字典如果需要的话。

I'm not aware of any new objects or functions that replicate the original implementation of TempData. Essentially we still use TempData but have to be mindful that the data persists until read and clear the dictionary manually if needed.

这篇关于TempData的实施改变 - 改变的原因的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！