其實這裏是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文件,例如下面這個:
- public class Handler1 : IHttpHandler {
- public bool IsReusable {
- get {
- return false;
- }
- }
我想不少人會對IsReusable這個屬性感到好奇,於是去查一下IHttpHandler的定義,找到這個解釋,
- // 摘要:
- // 獲取一個值,該值指示其他請求是否可以使用 System.Web.IHttpHandler 實例。
- //
- // 返回結果:
- // 如果 System.Web.IHttpHandler 實例可再次使用,則爲 true;否則爲 false。
- bool IsReusable { get; }
看到可以重用,有些對性能關注的人可能會將它修改爲返回true,其實改成什麼都一樣,因爲它不起作用。
不起作用的原因在這篇博客中有說明:http://www.cnblogs.com/fish-li/archive/2012/01/29/2331477.html
當前登錄用戶信息有時獲取不到
在ASP.NET中,提供了以下方法讓我們獲取當前用戶的信息,例如:
- if( HttpContext.Current != null ) {
- // 檢查當前用戶是否已爲一個已登錄用戶 bool isAuthenticated = HttpContext.Current.Request.IsAuthenticated;
- // 獲取當前請求的用戶名 string userName = HttpContext.Current.User.Identity.Name;
- }
不過,這段代碼放在不同的地方,效果卻截然不同。
最近就遇到一個問題:有人問我爲什麼總是取不當前用戶的用戶名。
網站採用的是Windows身份認證,因此,所有的請求都是經過IIS認證過的,理論上說,變量isAuthenticated應該返回true,而userName應該是當前請求的用戶名(Windows登錄名),然而呢,在調試時, isAuthenticated的值是false, 後面的代碼直接拋出一個空引用異常,因爲User對象爲null,太奇怪了,是嗎?
當出現這種情況時,我們應該檢查代碼在哪裏被調用的。
結果在我的追問下,發現代碼是在一個HttpModule中調用的,且發生在訂閱HttpApplication的BeginRequest事件中。找到這裏,原因也就找到了,此時(在這個階段)還沒有經過ASP.NET的身份認證檢查, User對象對象根本就沒有構造出來,現在去訪問,當然取不到結果。
憑良心說,這個還真算不上ASP.NET留給我們的坑,只怪一些人對管線事件不瞭解。
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,保存操作意味着需要執行序列化,還可以會有網絡傳輸的開銷,它們會影響性能。
如果上面的描述不容易理解的話,請看下面的示例代碼:
- string sessionValue = Session["s2"] as string;
- if( sessionValue == null ) {
- Session["s2"] = "Fish Li";
- sessionValue = Session["s2"] as string;
- }
當這個頁面首次運行時,Session被修改了,因此會有保存的操作發生。但是後面的訪問就不會有保存的動作。
再看另一段代碼:
- // TestData是一個自定義類型。TestData sessionValue = Session["s1"] as TestData;
- if( sessionValue == null ) {
- Session["s1"] = new TestData { IntValue = 5, StrValue = "Fish Li" };
- sessionValue = Session["s1"] as TestData;
- }
此時每次執行這段代碼時,都會有保存操作發生(只要是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類型時,它生成的結果會讓所有人感覺彆扭,其實序列化的結果表現形式還個小問題,在前端寫個轉換函數就能解決,然而,如果你需要 用序列化和反序列化的方法來做對象的持久化,就會遇到問題,例如下面的代碼:
- DateTime dt1 = DateTime.Now;
- JavaScriptSerializer jss = new JavaScriptSerializer();
- string json = jss.Serialize(dt1);
- DateTime dt2 = jss.Deserialize<DateTime>(json);
- context.Response.Write(dt1 == dt2);
瀏覽器顯示的結果會讓人感到很意外,竟然是:False
出現這個原因與JavaScript的時間格式有關,它使用了UTC時間,不過,這個理由讓人感到難以接受,畢竟其它的反序列化都能還原對象,例如二進制序列化和XML都能正確的還原對象。沒辦法,這裏只能算是個坑了,所以,如果你要做對象的持久化操作,儘量不要選擇JSON序列化。
原文鏈接:http://www.cnblogs.com/fish-li/archive/2013/05/28/3104750.html