你的位置:首页 > ASP.net教程

[ASP.net教程]对企业级应用开发的思考(2)


    在我们使用HTTP协议进行应用开发的的时候,通常服务器端是不关心请求是从哪个客户到来的,客户端也不并不关心服务器端是通过生成哪个对象处理的这次请求。这就是我们通常说的HTTP无状态请求,从技术的角度上讲是因为:

  • 客户端和服务器用TCP Socket通信,服务器将请求结果返回给浏览器后,通常会关闭Socket连接;
  • 服务器会在处理页面完毕后销毁页面对象;
  • HTTP协议本身就是一个无状态协议;

    举个例子,如返回一个Web页面告诉你关于一个商品的信息。可以通过访问一个URL请求服务器。在URL中带有该商品的ID号,服务器用它来产生HTTP页面进行响应。在这个过程中,服务器生成HTML页前可能记住了这个商品的ID以及从数据库取出来的商品名称/价格等信息,并可以通过业务逻辑来决定按哪种风格来显示给客户。一旦服务器完成工作,那些信息就没有任何作用了。

    然而我们的业务逻辑通常要求服务端与客户端交互是有状态的。最常见的是很多业务系统要登陆后才能进行操作,而且在整个操作过程中都要携带登陆信息,登陆信息便是会话状态;再比如网购过程中的购物车功能,购物车的内容就是会话状态。这些都是比较典型的基于状态的交互。基于会话的交互关键是如何存储会话状态信息,因为通信的两方只有客户端和服务端,所以会话状态的存储方式也有两种:存储在服务器端和存储在客户端。

客户端存储

    客户端存储能常有这样几种方法:数据编码在URL中、WEB表单的隐藏域中、HTML扩展标签及cookie。这里简单说一下具体的操作:

  • URL方法:这种方法最常见的就是在分页的时候,URL中带放有页码信息。比如:xx.aspx?page=3 这种方式是最简单有效的方法。但缺点也很明显,安全系数基本为0,而且只适合存储小数据量。
  • WEB表单隐藏域: 这种方式和把信息存储在HTML扩展标签中,还有可能在胖客户端的对象结构中其实是差不多一样的。最明显的一个例子就是asp.net中为表单自动生成的那一堆viewdata,它们的原理都是在客户端的WEB页面中放置一些普通用户看不见的东西。所以可以把它们归为一类,至于实际项目中选择使用哪种方式,全凭开发者个人爱好及客户浏览器的支持情况。它的一个典型的实现如下:
<input type="hidden" value="你的会话状态信息" id="sessionData"/>

  • Cookie:这是一种非常流行的做法。个人认为它流行的原因,很大一部分是因为程序编码者可以直接通过服务端代码实现,而不用像上面那种方式,还要去处理HTML。比如可以直接使用C#实现:
/// <summary>/// 写cookie值/// </summary>/// <param name="strName">名称</param>/// <param name="strValue">值</param>/// <param name="strValue">过期时间(分钟)</param>public static void WriteCookie(string strName, string strValue, int expires){  HttpCookie cookie = HttpContext.Current.Request.Cookies[strName];  if (cookie == null)  {    cookie = new HttpCookie(strName);  }  cookie.Value = strValue;  cookie.Expires = DateTime.Now.AddMinutes(expires);  HttpContext.Current.Response.AppendCookie(cookie);}/// <summary>/// 读cookie值/// </summary>/// <param name="strName">名称</param>/// <returns>cookie值</returns>public static string GetCookie(string strName){  if (HttpContext.Current.Request.Cookies[strName] != null)  {    return HttpContext.Current.Request.Cookies[strName].Value.ToString();  }  return "";}

     通过简单的服务端语言就可以实现cookie的读写,而且不需要处理任何数据传递/接收的处理。这样方便是方便,但以前面试过一些人,当问到为什么可以用服务器代码读写存在于客户端电脑上面的cookie时,令我吃惊的是,很多人就只敷衍一句,asp.net的内部机制,我们不用关心。我只想说这些人纯粹就是为了写代码而写代码,完全没有思考过其中的原因。

cookie

上图是cookie的标准流程图,在HTTP协议中有一些与cookie有关的扩展头部。帮助我们自动实现cookie信息在客户端与服务端传输。如下:

cookie2

    当在服务端写一个Cookie时,服务器在回传的HTTP中,会添加Set-Cookie把刚刚写入的内容传递到客户计算机中。当客户端再次请求该服务器时,会在请求的HTTP头中添加cookie信息,传递到服务器中,这样才能使服务器代码正常访问到。

服务器存储

    在服务器端存储会话信息通常有两个选择:直接存储在内存中序列化存储在文件系统中(当然,包括存储到数据库中)。对于面向对象的开发语言来说,通常使用静态数据对象(或集合)把状态存储在内存中,这样只想应用程序或服务器不重启,那么状态就可以一直存在,内存状态的典型代表就是asp.net内置的会话状态功能--Session。如果想把状态存储在文件或数据库中,最好的方法就是把会话标识作为关键字,以已序列化的对象为值进行存储。比如我们可以以SessionId作为关键字,把Session的内容序列化并存储到数据库中,这样就可以避免重启造成的Session丢失问题。关于Session的使用可以查看《认识asp.net会话状态》,本文不再详述。

    服务端存储并没有什么特殊要讲的地方,因为即不用考虑怎么把内容藏在客户电脑里面,并且让他们不易发现,也不用考虑太多安全问题。

 

抉择

    了解完两边的存储情况后,伴随而来的一个问题就是:我到底该把状态存在哪里?

    下表总结了一下,两种存储方式的优点及适用场景:

 优点适用场景
服务端存储数据安全性高;
简单,主流服务端开发的支持,大幅减少代码量;
本人是服务端会话存储的支持者,除下面列举的两种情况外,我基本都会把会话状态存储在服务器。
客户端存储用户客户端存储,减少服务器压力;1、适合会话状态数据量较少的情况;特别适合存放会话标识,典型的就是Session ID。
2、适合一些临时会话状态,比如购物车。因为用户可能经常取消该会话,并且再也不会用到它。

    两种模式在实际应用中并不是相互排斥的关系,且不存在绝对的谁好谁坏,可以灵活组合使用。但这样会增加程序编码的复杂度,开发者可以根据自己的情况选择使用。

 

    附:本博客其他精彩内容:http://www.cnblogs.com/yubaolee/p/Catalogue.html