ASP.NET常被忽视的一些细节

开发 后端
其实这里是ASP.NET应用程序中一个容易被忽略的经节。后来想想,类似这样的细节问题何止这一个,我今天就把我能想到的容易被忽视的细节问题都写出来,希望大家小心这些问题。

前段时间碰到一个问题:为什么在ASP.NET程序中定时器有时候会不工作? 

这个问题看起来很奇怪,代码好像也没错,但就是结果与预期不一致。

其实这里是ASP.NET应用程序中一个容易被忽略的经节。后来想想,类似这样的细节问题何止这一个,我今天就把我能想到的容易被忽视的细节问题都写出来,希望大家小心这些问题。 

想到我以前的博客中也零散的说过了一些,所以这篇博客中也把它们列出来了,不过,对于以前谈过的内容,这里将只会简略地说明。 

HttpContext.Current并非无处不在

这个问题是我上个月的博客中提到的问题,原文链接:http://www.cnblogs.com/fish-li/archive/2013/04/06/3002940.html

在以下情形中访问HttpContext.Current将会返回null

1. 定时器的回调。

2. Cache的移除通知。

3. APM模式下异步完成回调。

4. 主动创建线程或者将任务交给线程池来执行。 

所以,在写类库时,请注意这个问题。

Application_Start的异常与IIS经典模式

在IIS6或者II7的经典模式下运行ASP.NET程序时,如果Application_Start事件中抛出了未捕获异常,那么 这个异常将显示一次。

关于这个问题的更多细节介绍请点击:http://www.cnblogs.com/fish-li/archive/2013/03/24/2979780.html

QueryString,Form允许重复的KEY

我们经常见到的集合,例如:Hashtable, Dictionary,它们都要求KEY是唯一的,然而, HttpRequest的QueryString,Form集合实例却 允许KEY重复,当遇到KEY重复时,通过索引器访问集合时, 会将KEY对应的所有元素值用逗号拼接起来。

为什么会这样,因为这二个集合的类型是NameValueCollection,类似的,Headers集合也是这样。 

由于这个特殊性与我们常见的情形不一致,所以我们需要注意这个差别,当然了,有些时候我们还可以利用这个行为实现一些特殊的需求,关于这个细节的更多介绍请参考:http://www.cnblogs.com/fish-li/archive/2011/12/06/2278463.html ,在这篇博客中,还介绍了HttpRequest的二个索引器也是值得我们注意的。 

ashx的重用问题

很多ASP.NET的开发人员都应该创建过ashx文件,例如下面这个: 

 

  1. public class Handler1 : IHttpHandler {  
  2.     public bool IsReusable {  
  3.         get {  
  4.             return false;  
  5.         }  
  6.     }  

 

我想不少人会对IsReusable这个属性感到好奇,于是去查一下IHttpHandler的定义,找到这个解释, 

 

  1. // 摘要:  
  2. //     获取一个值,该值指示其他请求是否可以使用 System.Web.IHttpHandler 实例。  
  3. //  
  4. // 返回结果:  
  5. //     如果 System.Web.IHttpHandler 实例可再次使用,则为 true;否则为 false。  
  6. bool IsReusable { get; } 

 

看到可以重用,有些对性能关注的人可能会将它修改为返回true,其实改成什么都一样,因为它不起作用。

不起作用的原因在这篇博客中有说明:http://www.cnblogs.com/fish-li/archive/2012/01/29/2331477.html

当前登录用户信息有时获取不到

在ASP.NET中,提供了以下方法让我们获取当前用户的信息,例如: 

 

  1. if( HttpContext.Current != null ) {  
  2.  
  3.     // 检查当前用户是否已为一个已登录用户    bool isAuthenticated = HttpContext.Current.Request.IsAuthenticated;  
  4.  
  5.     // 获取当前请求的用户名    string userName = HttpContext.Current.User.Identity.Name;  
  6. }  

 

不过,这段代码放在不同的地方,效果却截然不同。 

最近就遇到一个问题:有人问我为什么总是取不当前用户的用户名。

网站采用的是Windows身份认证,因此,所有的请求都是经过IIS认证过的,理论上说,变量isAuthenticated应该返回true,而userName应该是当前请求的用户名(Windows登录名),然而呢,在调试时, isAuthenticated的值是false, 后面的代码直接抛出一个空引用异常,因为User对象为null,太奇怪了,是吗? 

当出现这种情况时,我们应该检查代码在哪里被调用的。

结果在我的追问下,发现代码是在一个HttpModule中调用的,且发生在订阅HttpApplication的BeginRequest事件中。找到这里,原因也就找到了,此时(在这个阶段)还没有经过ASP.NET的身份认证检查, User对象对象根本就没有构造出来,现在去访问,当然取不到结果。 

凭良心说,这个还真算不上ASP.NET留给我们的坑,只怪一些人对管线事件不了解。 

#p#

Timer可能会不起作用

有时候我们会遇到一些诸如执行定时任务的需求,于是有些人可能会想到用定时器来实现,在.net framework中,有二个Timer类型可以用于ASP.NET环境中,不过,Timer有可能会不起作用,具体表现情况也会让你难以描述:不知道在什么时候定时器就停止工作了。 

这个问题很奇怪:当你在调试模式下,定时器是一直能正常工作的,但当你把网站部署起来,运行时间久一些,便会发现定时器没有正常工作。 

为什么会这样呢?

答案是:当网站在一段时间没有请求后,进程会被IIS回收(释放)。

所以,在ASP.NET程序不适合执行【长久性】的定时任务,除非你能接受定时器会停止工作。

类似的问题还有:在ASP.NET程序中将某个方法做为回调方法传给Win32程序,发现回调没有响应。 

正是由于这个原因,建议将长久性的定时任务或者接收Win32回调的程序用Windows Service的程序来实现 

Session与复杂数据类型

Session有三种工作模式,拿ASPX页面来说,EnableSessionState指令有三个可选值:true, false, ReadOnly 

EnableSessionState="false",这个容易理解:不使用Session。 

EnableSessionState="ReadOnly",从字面上来说,就是Session是只读的。

只读的控件不允许用户修改,然而Session的只读模式是说:你可以改,但我不保存你的修改。这样理解没有问题吧。 

EnableSessionState="true",表示Session支持可读可写。

当你更新了Session的内容之后,当前会话的所有Session数据将会被重新保存。 

进程内Session容易丢失,且不支持多台Web服务器共享数据,因此选择这种保存方法的人不多,大多数人会选择状态服务或者SQL Server来保存,那么这里就有一个问题需要关注了:当Session模式是EnableSessionState="true"时,如果你访问了一个复杂对象(不是系统值类型也不是字符串),不管你有没有修改它,Session的保存操作都会执行。对于进程外Session,保存操作意味着需要执行序列化,还可以会有网络传输的开销,它们会影响性能。 

如果上面的描述不容易理解的话,请看下面的示例代码: 

 

  1. string sessionValue = Session["s2"as string;  
  2. if( sessionValue == null ) {  
  3.     Session["s2"] = "Fish Li";  
  4.     sessionValue = Session["s2"as string;  
  5. }  

 

当这个页面***运行时,Session被修改了,因此会有保存的操作发生。但是后面的访问就不会有保存的动作。 

再看另一段代码: 

 

  1. // TestData是一个自定义类型。TestData sessionValue = Session["s1"] as TestData;  
  2. if( sessionValue == null ) {  
  3.     Session["s1"] = new TestData { IntValue = 5, StrValue = "Fish Li" };  
  4.     sessionValue = Session["s1"as TestData;  
  5. }  

 

此时每次执行这段代码时,都会有保存操作发生(只要是EnableSessionState="true")。 

我再重申一遍:这个问题只有当EnableSessionState="true",且访问复杂对象(不是系统值类型也不是字符串)才会发生。对于进程内Session来说,这个问题的影响不大,但是对于进程外Session来说,会对性能产生一些影响,到底有多大的影响,要根据Session的数据量以及用户的并发度来决定。 

列出这个问题只是想告诉大家:如果你确实需要使用Session,请尽量在Session中保存【不可变】的简单数据,尤其是不要保持Session的默认设置(EnableSessionState="true")。 

检验这个问题的方法是:实现一个自定义的SessionStateStoreProviderBase派生类,然后调试观察。 SessionStateItemCollection的二个索引器也会给你一个答案。 

DateTime的JSON序列化

在SP.NET3.5中,微软为ASP.NET为设计了一个JSON序列化的工具类, System.Web.Script.Serialization.JavaScriptSerializer,这个类的使用很广泛,而且比WCF的那个JSON序列化类的兼容性要好。不过,这个类有一个问题,在序列化DataTime类型时,它生成的结果会让所有人感觉别扭,其实序列化的结果表现形式还个小问题,在前端写个转换函数就能解决,然而,如果你需要 用序列化和反序列化的方法来做对象的持久化,就会遇到问题,例如下面的代码: 

 

  1. DateTime dt1 = DateTime.Now;  
  2. JavaScriptSerializer jss = new JavaScriptSerializer();  
  3.  
  4. string json = jss.Serialize(dt1);  
  5. DateTime dt2 = jss.Deserialize<DateTime>(json);  
  6.  
  7. context.Response.Write(dt1 == dt2);  

 

浏览器显示的结果会让人感到很意外,竟然是:False 

出现这个原因与JavaScript的时间格式有关,它使用了UTC时间,不过,这个理由让人感到难以接受,毕竟其它的反序列化都能还原对象,例如二进制序列化和XML都能正确的还原对象。没办法,这里只能算是个坑了,所以,如果你要做对象的持久化操作,尽量不要选择JSON序列化。 

原文链接:http://www.cnblogs.com/fish-li/archive/2013/05/28/3104750.html

责任编辑:林师授 来源: 博客园
相关推荐

2012-07-03 13:55:00

ASP.NET

2009-09-04 13:11:25

ASP.NET生成XM

2011-04-29 09:35:43

打印纸打印机

2009-08-21 18:05:23

ASP.NET Ses

2009-08-04 16:06:19

ASP.NET代码分离

2009-12-11 14:17:36

ASP.NET Coo

2013-06-07 08:48:37

Android开发注意事项

2019-02-28 19:45:06

SQL错误用法数据库

2019-03-28 13:50:47

大数据面试Hadoop

2018-10-18 09:20:27

云计算配置错误

2009-08-14 17:49:02

ASP.NET MVC

2017-02-08 09:51:27

JavaScript细节

2022-04-27 22:07:32

SQL数据库分页查询

2009-07-31 18:00:35

ASP.NET工作流学

2022-10-20 07:47:46

2018-12-19 08:51:35

Docker动态工具

2009-08-03 18:16:46

ASP.NET Web

2015-05-20 11:06:54

2019-09-24 21:00:59

SQL数据库基础数据库

2010-01-28 10:11:18

IT金饭碗
点赞
收藏

51CTO技术栈公众号