|
ASP.NET 2.0支持兩種編譯模型(Compilation Model):
一為動態編譯(Dynamic Compilation),另一個為先行編譯(Precompilation)。
這讓程序設計師可以有更寬廣的選擇以決定不同網站何時該用何種編譯模型,不但彈性大大提升,且若採用先行編譯網站執行效能還可以更高,分述如下:
(一)ASP.NET網站動態編譯(Dynamic Compilation)
在ASP.NET 1.0時就已經支援網站動態編譯,也就是使用者第一次請求網站網頁時,ASP.NET會先將網站程式編譯成一個.dll組件檔,而后續的請求就會以此來回應,而編譯過后的網站執行效能明顯較未編譯網站快上許多。
然而雖說ASP.NET 1.0具有動態編譯的特性,但它只支援如.ASPx、.ascx、web.config或global.asax這幾種檔桉類型,只要它們有異動就會觸發系統進行動態編譯,但這個模式有個很明顯的問題存在,就是像bin目錄下的組件、資源檔、Web Services等等在程式設計階段也常進行修改,但這些檔桉即使用異動也不會觸發系統重新進行編譯,因此每每VS.NET 2003的專桉有修改異動,必須手動重新編譯整個專桉,如此使用瀏覽器執行網頁才會顯示最新修改的程式頁面。
但是可能不少人嫌煩或者是初學者根本不知道修改后要手動重新編譯,因此微軟針對動態編譯又再進行了更人性化的改良,現在針對類別、Web Service、具型別的DataSet、Master Page、Themes也支援異動時的動態編譯,各位只要針對IE瀏覽器重新Refresh就會自動觸發系統進行重新編譯,看到的也當然是最新的畫面,省卻程式設計師必須手動進行編譯,算是一個貼心的改良。
ASP.NET 2.0動態編譯和ASP.NET 1.0很像,但是更完美了,且當您建置(Build)整個Web網站后,在bin目錄并不會產生.dll的專桉程式,許多ASP.NET 1.0的程式設計師開始驚慌、疑惑與不安,為什麼找不到專桉.dll?沒有.dll檔要如何部署網站?等等的疑惑,其實沒什麼好疑惑的,各位之所以會疑惑是因為你把ASP.NET 1.0當作是普世的標準,凡是違反它的作法皆為異類,進而ASP.NET 2.0的動態編譯就成為您眼中的〝異類〞,但那是人的執著心與本位主義作崇的關係,事實上ASP.NET 2.0的動態編譯才是更完美,完美到根本不再需要.dll,只要有使用者進行請求時(Request),系統會自動進行動態編譯(仍然看不見.dll檔),所以若您要部署網站時,利用複製網站工具將.ASPx、.ASPx.cs、Web.config、類別檔全部複製一份到新網站就行了(唯獨沒有.dll檔),剩下的事情動態編譯會替您全部打理好。
(二)ASP.NET網站先行編譯(Precompilation)
除了上面所講的動態編譯外,ASP.NET 2.0尚提供先行編譯(Precompilation)網站的功能,它透過「ASPNET_ Compiler.exe」這個指令來預先編譯整個網站,祭司用通俗觀點來說明這樣的做法有幾個好處:
(1)節省網頁第一次編譯的時間。以往在ASP.NET 1.0這個編譯的機制雖然有效加速ASP.NET網站整體性能,但許多使用者或不明究裡的初學者卻抱怨第一次執行感覺好慢,而預先編譯整個網站是連第一次都省掉了,大概也不會有人再抱怨這個問題了。
(2)保護網頁程式碼智慧財產。在ASP.NET 1.0時可以將Code Behind編譯進dll之中,但是若是以In-Line Code開發或HTML標籤開發的程式則是一點保護作用也沒有;此外即便您用Code Behind模式開發Web應用程式,仍然會有許多標籤會產生在.ASPx之中,這種情況尤以ASP.NET 2.0更甚,如SqlDataSource連SQL命令都會顯示在HTML之中;故透過預先編譯不但連程式碼都可以編譯進去,甚至連.ASPx網頁中的HTML標籤也可以一併編譯進去,對于程式碼的保護可以說多了一層保障與選擇。
然而我們來看看微軟對于先行編譯好處的官方說法:
(1)由于頁面和程式碼檔不需在第一次要求時編譯,因此使用者可得到更快的回應時間,這對于經常更
新的大型網站特別有用。
(2)使用者瀏覽網頁之前,識別編譯時期錯誤的方法。
(3)不需原始程式碼,即可建立可部署到實際執行伺服器已編譯網站版本的能力。
NET技術:ASP.NET 2.0的編譯模型,轉載需保留來源!
鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播更多信息之目的,如作者信息標記有誤,請第一時間聯系我們修改或刪除,多謝。