为什么要在会话存储对象上使用asp.net的ViewState存储对象?

Other than because session storage is session-global to more than one page, why would you ever want to use the viewstate to hold values?

除了因为会话存储对多个页面都是会话全局的之外，为什么您要使用viewstate来保存值呢?

It seems kind of ridiculous to send any kind of information other than a few small query string like values, back and forth from the client to server. I mean what a waste of bandwidth(!), simply for storage purposes. The session, while global across multiple pages, seems like a completely superior alternative to the viewstate.

在客户端和服务器之间来回发送查询字符串(比如值)以外的任何类型的信息似乎都有点荒谬。我的意思是，仅仅为了存储目的而浪费带宽(!)尽管会话在多个页面上都是全局的，但它看起来完全是viewstate的更好选择。

Especially with asp.net ajax controls and variants, the viewstate could quickly become bloated tracking the various states and variables of all those different controls and html elements.

特别是使用asp.net ajax控件和变体，viewstate可能会迅速膨胀，跟踪所有这些不同控件和html元素的各种状态和变量。

But then why is there viewstate storage for page variables and objects at all?

但是为什么页面变量和对象有viewstate存储呢?

Maybe I'm missing another great usage for the page's viewstate storage, does anyone know something out there?

也许我错过了页面viewstate存储的另一个好用法，有人知道吗?

Thanks for reading!

感谢你的阅读!

EDIT: Everyone had a great answer, sorry if I didn't pick yours.

编辑:每个人都有一个很好的答案，如果我没选你的话，我很抱歉。

8 个解决方案

#1

Sessions run out, Viewstate does not - you can go back an hour later and your viewstate will still be available. Viewstate is also consistently available when you go back/forward on the website, Session changes.

会话耗尽，Viewstate不—您可以在一小时后返回，您的Viewstate仍然可用。当你在网站上返回/前进时，Viewstate也始终可用，会话改变。

#2

The whole reason for Viewstate or Session is to turn the web from a stateless system into a dynamic, customized experience. When a user requests a page, the only way you can resume where the user left off in their experience is to remember the state either on the server or on the user's client.

Viewstate或会话的全部原因是将web从无状态系统转变为动态的、定制的体验。当用户请求一个页面时，惟一能够恢复用户在其体验中中断的状态的方法是记住服务器或用户客户端的状态。

Viewstate is a mechanism for remembering the user's state on the client. Session is a mechanism for remembering the user's state on the server.

Viewstate是一种用于记住客户端的用户状态的机制。会话是一种机制，用于记住用户在服务器上的状态。

Viewstate is a transient storage mechanism. Controls that use viewstate have their state rendered into the html page as a hidden input. To prevent tampering, it is signed. It is not encrypted, however, so you probably want to avoid putting ANYTHING sensitive in there. Viewstate is useful for situations where you want to post across series of multiple requests (page loads). An example of this is when a form doesn't validate because maybe the user entered a bad email address or something, and you want to restore the form as it was before the user submitted. The downsides to this is that viewstate is a hungry beast and can easily add 30-50% to page size.

Viewstate是一种临时存储机制。使用viewstate的控件将其状态作为隐藏输入呈现到html页面中。为了防止篡改，签名。但是，它没有加密，因此您可能希望避免在其中放置任何敏感的内容。Viewstate对于跨一系列请求(页面加载)发布的情况非常有用。一个例子是当表单无法验证时，因为用户可能输入了一个糟糕的电子邮件地址或其他东西，而您希望恢复表单，因为它是在用户提交之前。这样做的缺点是viewstate是一个饥饿的野兽，可以很容易地将页面大小增加30-50%。

Session, on the other hand, is stored on the server. The client gets a token that tells the server which block of memory is theirs. This can be much more secure than viewstate because the data isn't being retransmitted to the user over and over. There are trade-offs though. Your server can run out of memory. Or, the user could lose the data if their session is disrupted.

另一方面，会话存储在服务器上。客户机获得一个令牌，该令牌告诉服务器哪个内存块是它们的。这可能比viewstate更安全，因为数据不会被反复传输给用户。有取舍。您的服务器可能耗尽内存。或者，如果用户的会话中断，用户可能会丢失数据。

Generally, there's no "right" answer on which to use. It is all about what you are trying to accomplish.

一般来说，没有正确的答案可以使用。这都是你想要完成的事情。

Most things to do with controls should use Viewstate. IF you're dealing with sensitive information however, consider Session. If you have data that is for a specific set of pages, use viewstate. If it is data that you will need throughout a user's visit on your site, considier Session.

与控件相关的大多数事情都应该使用Viewstate。但是，如果您正在处理敏感信息，请考虑会话。如果您有针对特定页面集的数据，请使用viewstate。如果是用户访问您的站点时需要的数据，那么就会更加一致。

#3

For example when your application might be running in a computer farm and you can't configure session to use sql server.( Or using sql server is too much of a performance hit)

例如，当您的应用程序可能在计算机机群中运行时，您不能配置会话来使用sql server。(或者使用sql server对性能的影响太大)

#4

ViewState and Session have different scopes. ViewState is designed to store more or less transient data, during "postbacks", while session is used to save critical session state data. I recommend using ViewState for state related to a specific "page session".

ViewState和会话有不同的作用域。ViewState设计用于在“回发”期间存储或多或少的临时数据，而会话用于保存关键的会话状态数据。我建议将ViewState用于与特定的“页面会话”相关的状态。

If you don't like the normal behavior of ViewState, it's pretty simple to write your own PageStatePersister and let this object perform persistence, for instance using session, or something like Memcached. You can then completely override the default persistence mechanism.

如果您不喜欢ViewState的正常行为，那么编写自己的PageStatePersister并让这个对象执行持久性(例如使用会话或类似Memcached)是非常简单的。然后可以完全覆盖默认的持久性机制。

Then, the good thing is you can seamlessly continue to use standard web controls in the .NET Framework, which will all use ViewState/ControlState for this type of data, without bloating the ViewState. A server memory persistence mechanism could be very efficient.

然后，好的方面是，您可以无缝地继续在. net框架中使用标准的web控件，该框架将为这种类型的数据使用ViewState/ControlState，而不会膨胀ViewState。服务器内存持久性机制可能非常有效。

#5

ViewState is essentially just a hidden input that must be uploaded to the server and parsed with each request. This field is typically populated automatically, often with the programmer blissfully unaware, and can grow quite large. For many sites that presents a problem, because even broadband users have very limited upstream bandwidth.

ViewState本质上就是一个隐藏的输入，必须上传至服务器并对每个请求进行解析。这个字段通常是自动填充的，通常程序员完全不知道，并且会变得非常大。对于许多出现问题的站点，因为即使是宽带用户也有非常有限的上游带宽。

On intranet sites where all the users have high-speed LAN access to the server but the ram available for holding session data is limited, it may make more sense.

在内部网站点中，所有用户都可以高速访问服务器，但是用于保存会话数据的ram是有限的，这可能更有意义。

#6

Not really a direct answer to your question, but it may resolve your issue.

这不是你问题的直接答案，但它可以解决你的问题。

You can store viewstate server side, eliminating the payload for the client.

您可以存储viewstate服务器端，消除客户端的有效负载。

Create a class the inherits page, and override the PageStatePersister. http://msdn.microsoft.com/en-us/library/system.web.ui.sessionpagestatepersister.aspx

创建继承页面的类，并覆盖PageStatePersister。http://msdn.microsoft.com/en-us/library/system.web.ui.sessionpagestatepersister.aspx

 public class RussPage : Page
    {
         protected override PageStatePersister PageStatePersister
        {
            get
            {
                return new SessionPageStatePersister(Page);
            }
        }
    }

#7

Not an answer to your question but one of your assumptions is incorrect.

不是你问题的答案，但你的一个假设是不正确的。

Session IDs can be passed in the URL. Session does not require cookies.

会话id可以在URL中传递。会话不需要cookie。

http://msdn.microsoft.com/en-us/library/aa479314.aspx

<sessionState cookieless="true" />

#8

You are doing an app where viewstate bloat, for the most part, is not an issue, then it's better to store page specific data in the viewstate because it helps your server perform better. If you go crazy with session, or any caching, for that matter, you can hurt yourself more then you help yourself.

您正在开发一个应用程序，在大多数情况下，viewstate膨胀都不是问题，那么最好在viewstate中存储页面特定的数据，因为这样可以帮助服务器更好地执行。如果你疯狂地使用会话，或者任何缓存，那么，你就会伤害你自己，然后你就可以帮助自己了。

#1