10

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

这转化为在一个请求中设置一个值、重定向并访问该行另一端的相同项目。在此之后，该条目将不再可用，无论您是否在行末从字典中读取该值。

自 ASP.NET MVC 3（我相信）以来，这个实现细节发生了相当大的变化。

中的条目TempDataDictionary现在只有在阅读后才会被删除。

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集合中，并在下一个请求中立即将它们读回，因此功能似乎大致相同。

在情况并非如此的情况下，例如希望在TempData重定向到一个位置时读取条目，并希望在请求其他资源并导航回来时将其删除，此更改会产生相当大的影响。

该条目不再可用于一个 http 请求，而是可用于许多 HTTP 请求，即使它仅可用于字典上的单个 get。

我想更多地了解这种实施变化，变化的原因是什么，这仅仅是为了迎合多个重定向还是有更深层次的好处？

其次，我很想知道是否有什么内置的东西现在可以像TempData过去一样满足单个 HTTP 请求共享数据的需求？

4

1 回答 1

6

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?

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.

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.

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.

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?

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.

于 2013-02-19T20:48:46.373 回答