适当情况下的ASP.NET状态管理

Question

在ASP.NET 3.5中有6种管理状态的技术（据我所知）。

(1) View State
(2) Cross Page Posting
(3) Query String
(4) Session State
(5) Application State
(6) Cookies

任何人都可以给我一些适当的例子来说明我应该使用这些技术吗？

例如：

(*) Session State: Personalization, Buy Cart, etc.
(*) Cookies: Saving User Credentials, etc.

Answer 1

有很多因素可以影响这一点，所以我不会评论所有这些因素。但这里有几点建议：

• ViewState - 当您经常回到同一页面时（这是ASP.Net Webforms实际上强制要做的事情），这非常有用。根据您正在构建的应用程序类型，它的确有多大用处。对于公共互联网站点，应该非常谨慎地使用它。您甚至可能希望在默认情况下将其关闭。对于本地Intranet站点，它是一个很好的工具 - 特别是对于更少，更重的webforms页面。

• Query String - 使用此选项可以存储您需要允许用户为页面或进程添加书签的状态，并在以后返回。即便如此，您可能希望将其保留为某种哈希值，您可以将其用作数据库查找中的键以避免真正巨大的URL（尽管哈希有自己的问题）。此外，很多用户喜欢直接调整你的查询字符串，所以在这里放太多是很危险的。很容易意外地将数据暴露给不应该以这种方式看到的用户。

• Application State - 请记住，这是由所有用户共享的，因此请正确使用。像查看计数之类的东西可以在这里。

• Cookies - 请勿使用Cookie来存储用户凭据。它们只是简单的未加密文本文件。使用cookie将密钥存储到会话中（即使在这里，您现在可以使用无cookie会话）以及特定于该用户和浏览器的简单个性化设置。例如，我在工作时的显示器大小与家庭不同，因此将显示大小/布局设置放入cookie中是很好的，因为每台计算机都有设置，但如果其他人读取该设置，则不会损害我的安全性。信息。

现在我想从“查询字符串”部分突出显示这个概念：

  

您可能希望将其保留为可用作数据库查找中的键的某种哈希

同样，哈希有自己的问题，但我想指出我列表中的几个项目（包括查询字符串）关于将数据从客户端Web浏览器上传到Web服务器：ViewState，Query String，Cookie和跨页面帖子。您希望最小化从客户端移动到服务器的数据。这个概念适用于所有这些，并且有几个原因：

1. 从公共网站上拉客户端的数据慢。即使是宽带连接，通常也会削弱可用于上传的带宽。与可能位于数据库和Web服务器之间的千兆以太网（或更快）连接相比，512Kpbs（在许多领域仍然是典型的宽带上传速率） nothing 。尽管您可能认为数据库查询速度很慢（并且确实如此），但仍然可能比等待来自客户端的相同数据更好。
2. 保持服务器上的数据更便宜，因为您不需要支付将其推送到客户端或从客户端推送所需的带宽，并且带宽通常比服务器硬件的成本高或多。
3. 它更安全，因为即使在客户端的计算机或连接遭到破坏时也能正确完成，所有黑客最初都可以访问的是一个哈希密钥，可能会在他解密时到期。当然，如果做错了，他可以立即直接使用该密钥，所以你仍然需要小心。

因此对于大多数事情，我建议首先将数据库密钥保存在Session中，然后让代码根据该密钥轻松地从数据库中提取所需内容。当您遇到瓶颈时，配置文件以找出它们的位置并开始缓存这些页面或控件，或者直接将该数据/查询结果保存在会话中。

Answer 2

州管理选项

查看状态：

当您需要为将回发给自己的页面存储少量信息时使用。使用ViewState属性提供基本安全性功能。

控制状态：

当您需要在往返服务器之间存储控件的少量状态信息时使用。

隐藏字段：

当您需要为页面存储少量信息时使用，该页面将回发到自己或其他页面，以及安全性不是问题。

您只能在提交给服务器的网页上使用隐藏字段。

饼干：

当您需要在客户端存储少量信息时使用，安全性不是问题。

查询字符串：

当您将少量信息从一个页面传输到另一个页面时使用，并且安全性不是问题。

只有在通过链接请求同一页面或其他页面时，才能使用查询字符串。

服务器端管理选项

申请状态

在存储许多用户使用的不经常更改的全局信息时使用，并且安全性不是问题。不要在应用程序状态下存储大量信息。

会话状态

当您存储特定于单个会话的短期信息并且安全性存在问题时使用。不要在会话状态中存储大量信息。请注意，将在应用程序的每个会话的生命周期中创建和维护会话状态对象。在托管许多用户的应用程序中，这会占用大量服务器资源并影响可伸缩性。

个人资料属性

在存储用户会话过期后需要保留的用户特定信息时使用，并且需要在后续访问应用程序时再次检索。

数据库支持

在存储大量信息，管理事务或信息必须在应用程序和会话重新启动后仍然存在时使用。数据挖掘是一个问题，安全性是一个问题。

Answer 3

不确定您是否按应用程序状态表示缓存对象。

Cache对象是管理应用程序范围状态的好方法，例如记录源和计数访问您的网站（例如，防止DDOS攻击）。

Answer 4

（3）查询字符串 （4）会议状态 （5）申请状态 （6）饼干

<强> 1。视图状态

• 免责声明：尽量少用。好的一点是总是让每个状态都可以通过URL访问，如果可能的话。
  • F.e。分页应该使用URL（所以/url/?p=2而不是将页面存储在Viewstate中）
• 用于在页面循环之间保持控制状态。
  • F.e。将所选项目存储在一个复选框中，以便您可以确定它是否已更改。

<强> 2。跨页发布

别。请参阅viewstate的免责声明。如果需要保留大量属性，请使用此URL，或将数据存储在会话/ cookie /配置文件中。

CPP的主要缺点是用户无法在其webbrowser中使用“后退”和“前进”按钮。当用户单击后退按钮时，它想要撤消该页面上的所有内容并重试最后一个页面。使用CPP通过向导单击它们时;如果没有很多“你确定要重新发送blablablabl”，这种行为是不可能的。

第3。查询字符串

使用很多。应该可以通过URL访问页面可以访问的每个可见状态。有屏幕阅读器的人会感谢你。通过使用查询字符串，无需使用仅限javascript的解决方案。

/url/?page=2    // when doing paging, don't use postback for this
/url/?tab=advanced-search    // when having tabs on top of your page

等

<强> 4。会话状态

将此项用于短期生活对象，只有在访问者访问您的网站时此时才有意义。例如：

• 达到了某个向导的哪一步
• 用户之前访问过的网页
• 要放入缓存中的小对象，但这些对象是用户绑定的

不要使用会话，而是使用以下内容：

• 选择
• 所选语言

因为下次用户访问您的网站时这些内容也很有意义。

<强> 5。申请状态

从不。使用ASP.NET缓存，或memcached，或任何缓存框架。

<强> 6。饼干

会话ID，经过身份验证的用户的配置文件ID;匿名用户的用户首选项（第4个列表中列出的所有内容。）。