在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.
Joel Coehoor.. 15
有很多因素可以影响这一点,所以我不会评论所有这些因素.但这里有一些指示:
ViewState - 当您经常回到同一页面时,这很有用(ASP.Net Webforms实际上强迫您这样做).根据您正在构建的应用程序类型,它的确有多大用处.对于公共互联网站点,应该非常谨慎地使用它.您甚至可能希望在默认情况下将其关闭.对于本地Intranet站点,它是一个很好的工具 - 特别是对于更少,更重的webforms页面.
Query String - 使用此选项可以存储允许用户为页面或进程添加书签所需的状态,并在以后返回.即便如此,您可能希望将其保留为某种哈希值,您可以将其用作数据库查找中的键以避免真正巨大的URL(尽管哈希有自己的问题).此外,很多用户喜欢直接调整你的查询字符串,所以在这里放太多是很危险的.很容易意外地将数据暴露给不应该以这种方式看到它的用户.
Application State - 请记住,这是由所有用户共享的,因此请正确使用.视图计数之类的东西可以在这里.
Cookies - 不要使用cookie来存储用户凭据.它们只是简单的未加密文本文件.使用cookie将密钥存储到会话中(即使在这里,您现在可以使用无cookie会话)以及特定于该用户和浏览器的简单个性化设置.例如,我在工作时的显示器大小与家庭不同,因此将显示大小/布局设置放入cookie中是很好的,因为每台计算机都有设置,但如果其他人读取该设置,则不会损害我的安全性.信息.
现在我想从"查询字符串"部分突出显示这个概念:
您可能希望将其保留为某种哈希,您可以将其用作数据库查找中的键
同样,哈希有自己的问题,但我想指出我列表中的几个项目(包括查询字符串)关于将数据从客户端Web浏览器上传到Web服务器:ViewState,Query String,Cookie和Cross-Page帖子.您希望最小化从客户端移动到服务器的数据.这个概念适用于所有这些,原因如下:
对于公共互联网站点,从客户端提取数据的速度很慢.即使是宽带连接,通常也会削弱可用于上传的带宽.与可能位于数据库和Web服务器之间的千兆以太网(或更快)连接相比,512Kpbs(在许多领域仍然是典型的宽带上传速率)并不算什么.尽管您可能认为数据库查询速度很慢(而且确实如此),但它仍然可能比等待从客户端到达相同数据更好.
保持服务器上的数据更便宜,因为您不需要支付将其推送到客户端或从客户端推送所需的带宽,并且带宽通常比服务器硬件的成本高或多.
它更安全,因为即使客户端的计算机或连接遭到破坏,如果正确完成,所有黑客最初都可以访问的是一个哈希密钥,可能会在他解密时到期.当然,如果做错了,他可以立即直接使用该密钥,所以你仍然需要小心.
所以对于大多数事情,我建议首先在Session中保留一个数据库密钥,然后让代码轻松地从基于该密钥的数据库中提取所需内容.当您遇到瓶颈时,可以通过配置文件找出它们的位置并开始缓存这些页面或控件,或者将该数据/查询结果直接保存在会话中.
有很多因素可以影响这一点,所以我不会评论所有这些因素.但这里有一些指示:
ViewState - 当您经常回到同一页面时,这很有用(ASP.Net Webforms实际上强迫您这样做).根据您正在构建的应用程序类型,它的确有多大用处.对于公共互联网站点,应该非常谨慎地使用它.您甚至可能希望在默认情况下将其关闭.对于本地Intranet站点,它是一个很好的工具 - 特别是对于更少,更重的webforms页面.
Query String - 使用此选项可以存储允许用户为页面或进程添加书签所需的状态,并在以后返回.即便如此,您可能希望将其保留为某种哈希值,您可以将其用作数据库查找中的键以避免真正巨大的URL(尽管哈希有自己的问题).此外,很多用户喜欢直接调整你的查询字符串,所以在这里放太多是很危险的.很容易意外地将数据暴露给不应该以这种方式看到它的用户.
Application State - 请记住,这是由所有用户共享的,因此请正确使用.视图计数之类的东西可以在这里.
Cookies - 不要使用cookie来存储用户凭据.它们只是简单的未加密文本文件.使用cookie将密钥存储到会话中(即使在这里,您现在可以使用无cookie会话)以及特定于该用户和浏览器的简单个性化设置.例如,我在工作时的显示器大小与家庭不同,因此将显示大小/布局设置放入cookie中是很好的,因为每台计算机都有设置,但如果其他人读取该设置,则不会损害我的安全性.信息.
现在我想从"查询字符串"部分突出显示这个概念:
您可能希望将其保留为某种哈希,您可以将其用作数据库查找中的键
同样,哈希有自己的问题,但我想指出我列表中的几个项目(包括查询字符串)关于将数据从客户端Web浏览器上传到Web服务器:ViewState,Query String,Cookie和Cross-Page帖子.您希望最小化从客户端移动到服务器的数据.这个概念适用于所有这些,原因如下:
对于公共互联网站点,从客户端提取数据的速度很慢.即使是宽带连接,通常也会削弱可用于上传的带宽.与可能位于数据库和Web服务器之间的千兆以太网(或更快)连接相比,512Kpbs(在许多领域仍然是典型的宽带上传速率)并不算什么.尽管您可能认为数据库查询速度很慢(而且确实如此),但它仍然可能比等待从客户端到达相同数据更好.
保持服务器上的数据更便宜,因为您不需要支付将其推送到客户端或从客户端推送所需的带宽,并且带宽通常比服务器硬件的成本高或多.
它更安全,因为即使客户端的计算机或连接遭到破坏,如果正确完成,所有黑客最初都可以访问的是一个哈希密钥,可能会在他解密时到期.当然,如果做错了,他可以立即直接使用该密钥,所以你仍然需要小心.
所以对于大多数事情,我建议首先在Session中保留一个数据库密钥,然后让代码轻松地从基于该密钥的数据库中提取所需内容.当您遇到瓶颈时,可以通过配置文件找出它们的位置并开始缓存这些页面或控件,或者将该数据/查询结果直接保存在会话中.
国家管理选择
查看状态:
当您需要为将回发给自己的页面存储少量信息时使用.使用ViewState属性提供基本安全性功能.
控制状态:
当您需要在往返服务器之间存储控件的少量状态信息时使用.
隐藏的字段:
当您需要为将回发到自身或其他页面的页面存储少量信息时,以及安全性不是问题时使用.
您只能在提交给服务器的页面上使用隐藏字段.
饼干:
当您需要在客户端上存储少量信息时使用,安全性不是问题.
请求参数:
当您将少量信息从一个页面传输到另一个页面时使用,并且安全性不是问题.
只有在通过链接请求同一页面或其他页面时,才能使用查询字符串.
服务器端管理选项
申请状态
在存储许多用户使用的不经常更改的全局信息时使用,并且安全性不是问题.不要在应用程序状态下存储大量信息.
会话状态
在存储特定于单个会话的短期信息时使用,并且安全性是个问题.不要在会话状态中存储大量信息.请注意,将在应用程序的每个会话的生命周期中创建和维护会话状态对象.在托管许多用户的应用程序中,这会占用大量服务器资源并影响可伸缩性.
档案属性
在存储用户会话过期后需要保留的用户特定信息时使用,并且需要在后续访问应用程序时再次检索.
数据库支持
在存储大量信息,管理事务或信息必须在应用程序和会话重新启动后仍然存在时使用.数据挖掘是一个问题,安全性是一个问题.
京公网安备 11010802040832号 | 京ICP备19059560号-6 