选择会话状态还是 ViewState？
在某些情况下，将状态值保存在 ViewState 中并不是最佳选择，最常用的替代方法就是会话状态，它通常更适用于：
大量的数据。由于 ViewState 增加了发送到浏览器的页面的大小（HTML 有效负载），同时也增加了回传的窗体的大小，因此不适合存储大量数据。
未在 UI 中显示的安全数据。尽管 ViewState 数据已被编码，并且可以选择对其进行加密，但始终不将数据发送到客户端才是最安全的。因此，会话是更安全的选择。（由于数据库需要额外的凭据进行验证，因此将数据存储在数据库中会更安全。可以添加 SSL 以获得更安全的链接。）但是，如果在 UI 中已经显示了该专用数据，那么您应该已经确认了链接的安全性。在这种情况下，将同样的值放入 ViewState 不会降低安全性。
尚未序列化到 ViewState 中的对象，如 DataSet。ViewState 序列化程序只为一小部分常用的对象类型进行了优化，如下所示。其他可序列化的类型或许可以保留在 ViewState 中，但速度会变慢，并会生成一个非常大的 ViewState。
会话状态 ViewState
是否使用服务器资源？ 是 否
是否超时？ 是，20 分钟后（默认） 否
是否存储所有 .NET 类型？ 是 否，仅支持：String、Integer、Boolean、Array、ArrayList、Hashtable 和自定义 TypeConverter
是否增加“HTML 有效负载”？ 否 是
使用 ViewState 获得最佳性能
使用 ViewState 时，每个对象都必须先序列化到 ViewState 中，然后再通过回传进行反序列化，因此使用 ViewState 并非是没有代价的。但是，如果遵循某些简单的原则对 ViewState 的成本加以控制，则通常不会产生明显的性能影响。
在不需要时禁用 ViewState。下面的“减少使用 ViewState”一节将详细介绍这一问题。
使用优化过的 ViewState 序列化程序。上面列出的类型具有专门的序列化程序，这些程序运行速度很快，并已经过优化，可以生成很小的 ViewState。如果要序列化一个未在上面列出的类型，可以创建一个自定义 TypeConverter 来显著提高它的性能。
尽量减少使用对象，如果可能，尽量减少放入 ViewState 中的对象的数目。例如，不要使用二维字符串数组（名称/值，其对象的数目与数组的长度一样多），而应使用两个字符串数组（只有两个对象）。但是，在将两个已知类型存储在 ViewState 中之前，在这两者之间转换不会获得任何性能提高，因为这样做实际上相当于付出了两次转换的代价。
减少使用 ViewState
默认情况下 ViewState 将被启用，并且是由每个控件（而非页面开发人员）来决定存储在 ViewState 中的内容。有时，这一信息对应用程序并没有什么用处。尽管也没什么害处，但却会明显增加发送到浏览器的页面的大小。因此如果不需要使用 ViewState，最好还是将它关闭，特别是当 ViewState 很大的时候。
可以基于每个控件、每个页面或每个应用程序来关闭 ViewState。在以下情况中将不再需要 ViewState：
页面 控件
页面不回传给自身。
处理的不是控件的事件。
控件没有动态的或数据绑定的属性值（或对于每一个请求它们都设置在代码中）。
DataGrid 控件是 ViewState 的一个重量级用户。默认情况下，在网格中显示的所有数据也都存储在 ViewState 中，当需要一个复杂的操作（如复杂的搜索）来获取数据时，这是非常有用的。但是，DataGrid 的这种行为有时也使得 ViewState 成为累赘。
例如，这里有一个简单的页面就属于上述情况。因为页面不回传给自身，所以它并不需要 ViewState。
图 3：带有 DataGrid1 的简单页面 LessViewState.ASPx
<%@ Import Namespace="System.Data" %>
启用 ViewState 时，这个小网格会给该页面增加 3000 多字节的 HTML 有效负载！使用 ASP.NET Tracing（英文）或查看发送到浏览器的页面的源代码（如以下代码所示），可以清楚地看到这一点。
[C#]
<%@ Page Language="C#" %>
<%@ Import Namespace="System.Data" %>
禁用 ViewState
在上述示例中，我通过将网格的 EnableViewState 属性设置为 False 禁用了 ViewState。可以针对单个控件、整个页面或整个应用程序禁用 ViewState，如下所示：
每个控件（在标记上）
每个页面（在指令中） <%@ Page EnableViewState="False" ?%>
每个应用程序（在 web.config 中）
使 ViewState 更安全
由于 ViewState 没有被格式化为清晰的文本，某些人有时会认为它被加密了，其实并没有。相反，ViewState 只是进行了 Base64 编码，以确保值在往返过程中不会发生变化，而并不考虑应用程序使用的响应/请求编码。
可以向应用程序中添加两种 ViewState 安全级别：
防篡改
加密
需要注意的是，ViewState 安全性对于处理和呈现 ASP.NET 页面所需的时间有直接的影响。简单地说，安全性越高，速度越慢。因此如果不需要，请不要为 ViewState 添加安全性。
防篡改
尽管散列代码不能确保 ViewState 字段中实际数据的安全，但它能够显著降低有人通过 ViewState 骗过应用程序的可能性，即防止回传应用程序通常禁止用户输入的值。
可以通过设置 EnableViewStateMAC 属性来指示 ASP.NET 向 ViewState 字段中追加一个散列代码：
<%@Page EnableViewStateMAC=true %>
可以在页面级别上设置 EnableViewStateMAC，也可以在应用程序级别上设置。在回传时，ASP.NET 将为 ViewState 数据生成一个散列代码，并将其与存储在回传值中的散列代码进行比较。如果两处的散列代码不匹配，该 ViewState 数据将被丢弃，同时控件将恢复为原来的设置。
默认情况下，ASP.NET 使用 SHA1 算法来生成 ViewState 散列代码。此外，也可以通过在 machine.config 文件中设置
加密
可以使用加密来保护 ViewState 字段中的实际数据值。首先，必须如上所述设置 EnableViewStatMAC="true"。然后，将 machineKey validation 类型设置为 3DES。这将指示 ASP.NET 使用 Triple DES 对称加密算法来加密 ViewState 值。
Web 领域中的 ViewState 安全性
默认情况下，ASP.NET 将创建一个随机的验证密钥，并存储在每个服务器的本地安全授权 (LSA) 中。要验证在另一台服务器上创建的 ViewState 字段，两台服务器的 validationKey 必须设置为相同的值。如果要通过上述方式之一，对运行于 Web 领域配置中的应用程序进行 ViewState 安全设置，则需要为所有服务器提供一个唯一的、共享的验证密钥。
验证密钥是一个包含 20 到 64 位密码增强字节的随机字符串，用 40 到 128 个十六进制字符表示。密钥越长越安全，因此建议使用 128 个字符的密钥（如果计算机支持）。例如：
System.Security.Cryptography 名称空间包括 RNGCryptoServiceProvider 类，使用该类可以生成此字符串，如以下 GenerateCryptoKey.ASPx 示例所示：
<%@ Page Language="c#" %>
<%@ Import Namespace="System.Security.Cryptography" %>
总结
ASP.NET ViewState 是一种新的状态服务，可供开发人员基于每个用户来跟踪 UI 状态。ViewState 没有什么神秘之处，它只是利用了一个老的 Web 编程技巧：在一个隐藏的窗体字段中来回传递状态，并将它直接应用于页面处理框架中。但效果却非常好 - 在基于 Web 的窗体中只需编写并维护很少的代码。
用户可能并不总是需要它，但我想您在需要它的时候会发现，ViewState 是提供给页面开发人员的诸多 ASP.NET 新功能中非常令人满意的一种功能。