成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

如何在ASP.NET應用程序中初始化

開發 后端
今天給大家介紹了4種在ASP.NET中執行初始化的方法,或許有些人會想:到底該選擇哪種初始化方法呢?的確,方法越多越讓人迷惑。

每個程序都需要初始化的過程,用來讀取配置或者設置一些運行環境(變量),對于ASP.NET程序來說,又該在哪里執行初始化的任務呢?

我想應該絕大多數人都知道在Global.asax中執行初始化的過程,然而有些細節是我們需要關注的。

本文用例

在這篇博客的示例代碼中,AppInitializer包含了網站的初始化的實現代碼:

  1. public static class AppInitializer  
  2. {  
  3.     public static ConnectionStringSettings MyNorthwindConnectionSetting { getprivate set; }  
  4.  
  5.     public static void Init()  
  6.     {  
  7.         // 讀取連接字符串。  
  8.         LoadConnectionString();  
  9.  
  10.         // 設置SQLSERVER緩存依賴通知。  
  11.         SetSqlDependency();  
  12.  
  13.         // 其它的初始化操作。  
  14.         OthersInit();  
  15.     }  
  16.  
  17.     static void LoadConnectionString()  
  18.     {  
  19.         ConnectionStringSettings setting = ConfigurationManager.ConnectionStrings["MyNorthwind"];  
  20.         if( setting == null )  
  21.             throw new ConfigurationException("沒有配置MyNorthwind連接字符串。");  
  22.  
  23.         ifstring.IsNullOrEmpty(setting.ConnectionString) )  
  24.             throw new ConfigurationException("沒有為MyNorthwind連接字符串指定內容。");  
  25.  
  26.         ifstring.IsNullOrEmpty(setting.ProviderName) )  
  27.             throw new ConfigurationException("沒有為MyNorthwind連接字符串指定ProviderName 。");  
  28.  
  29.         // 保存讀取到的連接字符串,供程序使用。  
  30.         MyNorthwindConnectionSetting = setting;  
  31.     }  
  32.  
  33.     static void SetSqlDependency()  
  34.     {  
  35.         // 判斷SQLSERVER版本是否為 2005以上版本,  
  36.         // 是否開啟Service Broker的檢查代碼就不列出了。  
  37.  
  38.         SqlDependency.Start(MyNorthwindConnectionSetting.ConnectionString);  
  39.     }  
  40.  
  41.     static void OthersInit()  
  42.     {  
  43.         // 其它的初始化操作。  
  44.  
  45.         // 例如:  
  46.         // 1. 加載必要的緩存數據。  
  47.         // 2. 檢查上傳目錄是不存在。  
  48.         // 3. ...................  
  49.     }  

這段代碼的意圖很清楚,一定要確保正確的配置了數據庫連接字符串,否則以異常的形式報告出來。

示例程序還有一個頁面,Default.aspx

  1. <body> 
  2.     <form id="form1" runat="server"> 
  3.     <div> 
  4.         <h1>User Login</h1> 
  5.     </div> 
  6.  
  7.         <p style="line-height: 150%;"> 
  8.             UserName: <asp:TextBox ID="txtUserName" runat="server" Width="200px" Text="Fish Li"></asp:TextBox><br /> 
  9.             Password: <asp:TextBox ID="txtPassword" runat="server" Width="200px" TextMode="Password"></asp:TextBox><br /> 
  10.             <asp:Button ID="btnLogin" runat="server" Text="登錄" OnClick="btnLogin_Click" /> 
  11.         </p> 
  12.     </form> 
  13. </body> 

其實就是一個登錄頁面,后臺代碼為:

  1. protected void btnLogin_Click(object sender, EventArgs e)  
  2. {  
  3.     bool ok = false;  
  4.  
  5.     using( SqlConnection connection  
  6.         = new SqlConnection(AppInitializer.MyNorthwindConnectionSetting.ConnectionString) ) {  
  7.  
  8.         connection.Open();  
  9.  
  10.         // 其它的數據庫操作。  
  11.  
  12.         ok = true;  
  13.     }  
  14.  
  15.     if( ok )  
  16.         Response.Redirect("Default2.aspx");  

你沒有想到的Global.asax怪事!

或許有些人會這樣寫他們的初始化代碼:

  1. void Application_Start(object sender, EventArgs e)  
  2. {  
  3.     //在應用程序啟動時運行的代碼  
  4.     try {  
  5.         AppInitializer.Init();  
  6.     }  
  7.     catch( Exception ex ) {  
  8.         LogException(ex);  
  9.           
  10.         // .....................  
  11.     }  
  12. }  

這段代碼有什么問題呢?

其實問題的線索在于:為什么要加try....catch語句,是因為知道可能會發生異常嗎?

如果真有異常情況發生,這樣處理后,后續的請求是不是會發生各種想像不到的錯誤?

顯然這里不能吃掉異常,要不然后面的請求肯定會有問題,因為它們依賴的設置沒有正確的初始化。

好吧,那我去掉 try.....catch語句,這樣總該行了吧:

  1. void Application_Start(object sender, EventArgs e)  
  2. {  
  3.     //在應用程序啟動時運行的代碼  
  4.  
  5.     AppInitializer.Init();  
  6. }  

還是看來一下真實的運行情況吧。

噢,抱歉,我還真忘記了配置連接字符串,這個異常提示太給力了。

現在就加上連接字符串嗎?

別急,想像一下,如果這個網站是一個真實的在線網站,會是什么情況呢?
答案有二種:

1. 另一個用戶也發起了一次請求。

2. 當前用戶看到錯誤頁面后,重新刷新了一次當前頁面。

現在我用Opera來扮演第二個瀏覽用戶吧,還是打開同樣的網址。

太奇怪了,第二個用戶居然能打開頁面,好吧,讓他登錄試試。

結果第二個用戶看到的錯誤情況和第一個用戶完全不同。

如果此時第一個用戶刷新他的瀏覽器,發現頁面又可以顯示了,然而登錄時,會看到與第二個用戶一樣的異常信息。

這個示例代碼實在太簡單了,我想維護人員根據NullReferenceException這個線索找下去,很快就能找到答案。如果初始化代碼再復雜一些,比如SetSqlDependency()中出現異常呢,那么程序仍然能夠正常運行,但是我們期望的緩存依賴可能就沒有效果了,最終可能會產生性能問題,排查的難度就會大多了。

記得以前做項目時,就遇到過這種情況,當時感到很奇怪,為什么刷新一下就沒黃頁了,不過后面的錯誤就很折騰人了,最終也讓我總結了這個教訓。所以我建議:如果在初始化階段出現了異常,干脆就別讓程序繼續運行了,每個請求都直接顯示黃頁,直到排除故障為止。

#p#

如何保證初始化異常一直顯示?

當初始化發生異常時,如何保證初始化異常一直顯示呢?

方法其實并不難,我們需要修改一下代碼:

  1. private static Exception s_initException;  
  2.  
  3. void Application_Start(object sender, EventArgs e)  
  4. {  
  5.     try {  
  6.         AppInitializer.Init();  
  7.     }  
  8.     catch( Exception ex ) {  
  9.         // 記下初始化的異常。  
  10.         s_initException = ex;  
  11.     }      
  12. }  
  13.  
  14. protected void Application_BeginRequest(object sender, EventArgs e)  
  15. {  
  16.     // 如果存在初始化異常,就拋出來。  
  17.     // 直到開發人員發現這個異常,并已解決了異常為止。  
  18.     if( s_initException != null )  
  19.         throw s_initException;  
  20. }  

現在不管有多少個用戶來訪問,或者第一個訪問者刷新瀏覽器多少次,都會看到同樣的異常信息:

說明:Global.asax的這個問題在IIS7以上版本的集成模式下并不存在。

還有哪些初始化方法?

除了Global.asax中的Application_Start,還有哪些方法可以在ASP.NET程序執行初始化的任務呢?

目前我知道的還有另三種方法:

1. App_Code中的AppInitialize方法。

2. 寫個專用的HttpModule。

3. ASP.NET 4.0的PreApplicationStartMethodAttribute

App_Code中的AppInitialize方法

ASP.NET允許我們在App_Code中的任何一個類型定義一個AppInitialize方法,用它也能執行初始化的任務。

  1. public class Class1  
  2. {  
  3.     public static void appInitialize()  
  4.     {  
  5.         AppInitializer.Init();          
  6.     }  
  7. }  

如果我此時再次運行示例程序(已注釋掉Global.asax中的代碼),會看到以下顯示:

顯然,我們期望的初始化代碼確實被調用了。

這個AppInitialize方法有什么限制呢?

我們還是來看一下ASP.NET的源代碼吧:

  1. internal class BuildResultMainCodeAssembly : BuildResultCompiledAssembly  
  2. {  
  3.     private MethodInfo FindAppInitializeMethod(Type t)  
  4.     {  
  5.         return t.GetMethod("AppInitialize",   
  6.             BindingFlags.Public | BindingFlags.Static | BindingFlags.IgnoreCase,   
  7.             nullnew Type[0], null);  
  8.     }  

根據代碼我們可以發現AppInitialize方法的特點有:

1. 必須是一個公開的靜態方法:BindingFlags.Public | BindingFlags.Static

2. 方法名不區分大小寫:BindingFlags.IgnoreCase

3. 方法不允許有傳入參數:new Type[0]

HttpModule也能執行初始化的任務

由于HttpModule總是會在ASP.NET管線中被調用,所以,我們還可以用它來完成初始化的操作。

  1. public class InitAppModule : IHttpModule  
  2. {  
  3.     public void Init(HttpApplication context)  
  4.     {  
  5.          //注意:Init事件可能被多次調用,所以這個方法會被多次調用。  
  6.  
  7.         AppInitializer.Init();  
  8.     }  

正如代碼注釋所說的那樣,這種調用代碼是不對的,除非你能接受初始化代碼被多次調用!

所以,我們應該按單例模式的思路來改寫代碼:

  1. private static readonly object s_lock = new object();  
  2. private static bool s_initOK;  
  3.  
  4. public void Init(HttpApplication context)  
  5. {  
  6.     lock( s_lock ) {  
  7.         if( s_initOK == false ) {  
  8.             //保證初始化代碼只執行一次。  
  9.  
  10.             AppInitializer.Init();  
  11.             s_initOK = true;  
  12.         }  
  13.     }  
  14. }  

如果你希望代碼簡單一點,還可以這樣實現:

  1. public class InitAppModule : IHttpModule  
  2. {  
  3.     static InitAppModule()  
  4.     {  
  5.         AppInitializer.Init();  
  6.     }  
  7.     public void Init(HttpApplication context)  
  8.     {  
  9.         // 留個空方法,  
  10.         // ASP.NET會調用這個方法,最后能觸發靜態方法的調用。  
  11.     }  

ASP.NET 4.0新增的初始化方法

為了讓一些類庫能自動執行一些初始化,ASP.NET提供了一種新方法,允許為程序集指定一個PreApplicationStartMethodAttribute

為了演示這種用法,我將前面的示例(VS2008開發)移到一個類庫中(用VS2012開發)并設置類庫的命名空間為InitClassLibrary1。

然后,我添加了一個調用類:

  1. namespace InitClassLibrary1  
  2. {  
  3.     public class Class1  
  4.     {  
  5.         public static void InitApp()  
  6.         {  
  7.             AppInitializer.Init();  
  8.         }  
  9.     }  

最后,我們可以在InitClassLibrary1類庫的AssemblyInfo.cs文件中,增加一個Attribute

  1. [assembly: System.Web.PreApplicationStartMethod(  
  2.                 typeof(InitClassLibrary1.Class1), "InitApp")]  

當然了,你也可以直接像下面設置,免得多創建一個類型出來:

  1. [assembly: System.Web.PreApplicationStartMethod(  
  2.                 typeof(InitClassLibrary1.AppInitializer), "Init")]  

這樣設置后,再運行網站,你也能發現我們的初始化代碼確實運行了:黃頁仍然在顯示。

#p#

各種初始化方法的差別

前面介紹了4種在ASP.NET執行初始化的方法,你或許想知道它們到底有哪些區別呢?

由于它們都能實現初始化的操作,它們的差別也只有執行的時刻不同而已,我們可以用簡單的方法區分它們的調用位置:看異常的調用堆棧信息。

AppInitialize方法異常時的調用堆棧信息:

HttpModule異常時的調用堆棧信息:

PreApplicationStartMethodAttribute異常時的調用堆棧信息:

Global.asax的Application_Start事件處理器的調用方式則不同,ASP.NET采用了反射調用,當異常發生只保留了內部異常,我們看不到調用堆棧(不信的話,自己去試試)。

沒關系,既然ASP.NET不告訴我們調用堆棧信息,我們自己也可以去取,請看下面的代碼:

  1. void Application_Start()  
  2. {  
  3.     System.Diagnostics.StackTrace stack = new System.Diagnostics.StackTrace();  
  4.     System.IO.File.WriteAllText("h:\\Application_Start_stack.txt", stack.ToString());  
  5. }  

再打開文件看一下吧。

說明:Global.asax的Application_Start事件處理器還有幾種等效的方法:

  1. // 這二個方法都可以實現與Application_Start(object sender, EventArgs e)相同的行為。  
  2.  
  3. void Application_OnStart()  
  4. {  
  5. }  
  6.  
  7. void Application_Start()  
  8. {  
  9. }  

根據以上分析,可以可以得知:

1. AppInitialize和PreApplicationStartMethodAttribute指向的方法被調用的時機發生在ASP.NET創建宿主環境時,屬于比較早的時刻。

2. Application_Start和HttpModule的調用時刻要晚一點。

這個結論有用嗎?

其實我也感覺意義不大,不過分析它僅僅為了滿足我的求知欲和好奇心而已,你是否也有這樣的好奇心呢?

如果你仍然好奇想知道這4種方法的執行時機的先后順序,我也能告訴你:

1. PreApplicationStartMethodAttribute指向的方法。

2. App_Code中的appInitialize方法。

3. Application_Start。

4. HttpModule

再補充一點:在開發環境中,當我們編譯網站時,PreApplicationStartMethodAttribute指向的方法可能會被調用,這處決于類庫的程序集是否發生了修改。

到底該選擇哪種初始化方法?

今天給大家介紹了4種在ASP.NET中執行初始化的方法,或許有些人會想:到底該選擇哪種初始化方法呢?

的確,方法越多越讓人迷惑。

下面的觀點僅代表我個人的建議,你也可以根據自己的喜好來選擇。

1. 優先選擇Application_Start(雖然IIS的經典模式下需要多寫點代碼),因為任何人找初始化代碼時都會想到那里,便于其他人維護。

2. AppInitialize方法雖然使用簡單,但它并不適合于WebApplication項目。

3. PreApplicationStartMethodAttribute只支持ASP.NET 4.0以上版本,且尤其適合于類庫的內部初始化。

4. 當以上方法都不可行時,HttpModule將成為最后的救命稻草,它適合所有ASP.NET版本。

原文鏈接:http://www.cnblogs.com/fish-li/archive/2013/03/24/2979780.html

責任編輯:張偉 來源: 博客園
相關推薦

2009-03-30 10:34:03

ASP.NETMySQL

2009-07-29 10:30:53

Web應用程序ASP.NET

2017-04-21 12:03:46

MacASP.NET Cor程序

2009-07-21 15:02:19

ASP.NET應用程序

2009-07-22 17:32:40

ASP.NET應用程序

2009-07-23 13:26:21

2009-07-27 16:09:50

2009-07-29 17:01:13

2009-08-05 10:16:54

部署ASP.NET應用

2009-07-20 16:08:04

ASP.NET應用程序

2009-07-23 14:25:03

ASP.NET 2.0

2009-07-29 17:21:10

2009-07-22 18:02:27

論壇應用程序ASP.NET MVC

2009-07-22 18:07:55

論壇應用程序ASP.NET MVC

2009-07-27 17:46:42

WCF服務ASP.NET應用程序

2009-07-24 11:25:53

Web應用程序工程ASP.NET MVC

2009-07-28 10:11:06

ASP.NET應用程序

2009-08-04 11:46:09

2009-07-21 15:23:55

預編譯Web應用程序ASP.NET

2009-07-21 15:14:32

預編譯應用程序ASP.NET
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 97av在线| 99久热| 国产欧美在线视频 | h在线观看 | 中文字幕日韩欧美 | 久久久久久美女 | 国产精品久久久久久久久免费软件 | 日韩中文字幕在线 | 久久影音先锋 | 精品一区二区免费视频 | 久久精品久久精品久久精品 | 视频三区 | 国产精品久久网 | 中文字幕乱码一区二区三区 | 欧美 日韩 国产 一区 | 在线观看av网站永久 | 天天天操 | 中文字幕国产在线 | 九九亚洲| 久久99久久99精品免视看婷婷 | 亚洲精品一区二区三区蜜桃久 | 久久久免费在线观看 | 国产美女在线观看 | 国产乱一区二区三区视频 | 在线国产欧美 | 国产美女在线播放 | 一级黄色绿像片 | 午夜激情视频在线 | 日韩精品在线观看一区二区三区 | 亚洲免费视频网站 | 亚洲精品99| 国产成人精品a视频一区www | 精品国产久 | 国内精品免费久久久久软件老师 | 蜜桃视频在线观看免费视频网站www | 国产亚洲网站 | 欧美一区二区 | 久久久影院 | 日日夜夜精品视频 | 99国产精品一区二区三区 | 久久综合一区二区 |