優(yōu)化和緩沖存儲. 這是怎樣辦到的呢?

　　根據(jù)腳本的首次請求, runtime將代碼進行編譯,并將編譯結(jié)果進行高速緩沖存儲復制(備份). 不論何時,只要腳本有請求,被存儲的副本都可以調(diào)出使用. 此結(jié)果大大的增強了系統(tǒng)性能, 因為在首次請求之后,代碼能更快的從編譯版本中運行.

　　有人也許就會問了”它怎么知道我什么時候作了改動?” 微軟已對此作出解答.Runtime通過文件系統(tǒng)來監(jiān)視源文件. 當初始源文件發(fā)生改變時,它自動將編譯版本從高速緩沖存儲備份中拖出,因此當下一個要求來臨時,它(編譯文件)會被重新編譯.這就意味著系統(tǒng)會自動編譯代碼, 程序員就再也用不著為人工編譯而頭疼了.

　　caching

　　對于多數(shù)的系統(tǒng)開發(fā)者而言，他們必須研制出一些“caching”來使系統(tǒng)速度加快。無論是ASP頁面輸出到HTML文件格式,網(wǎng)絡聯(lián)結(jié)速度都非常慢�；蚴菑木徛�的internet鏈接引用,到recordset的 狀態(tài)和漫游表單上的email表示符,甚至一個數(shù)據(jù)庫動態(tài)驅(qū)動菜單，實際上不是完全的動態(tài)驅(qū)動,你不能為你每個客戶請求而浪費大量時間。在創(chuàng)建網(wǎng)站時，一般來說，少量數(shù)據(jù)不會持續(xù)改變，但是正因為它們不是真正意義上的動態(tài)，不意味著使代碼復雜化，那么它們在哪兒呢？所以，你得開發(fā)一些caching

　　基本的 caching 活動是首先甄選適當?shù)臄?shù)據(jù)進行存儲。然后你需要將它們放置在程序中的application級變量中。然后，識別代碼。然后，你就得決定得將數(shù)據(jù)存儲多久，并寫出程序，以便及時清空caching.但是，如果你清空了caching的話，那么所使用的程序得具有使數(shù)據(jù)重新恢復的功能。

　　在ASP.NET中建立了CACHING系統(tǒng)。使得使得整個系統(tǒng)比以前更為面向?qū)ο�，使�?caching系統(tǒng)也可以存儲 對象 。因此，無論何時caching，也可以隨時調(diào)用。你可以根據(jù)需要設置數(shù)據(jù)存儲的時間來決定創(chuàng)建各種類型的環(huán)境。 通過文件系統(tǒng)，你甚至可以在文件上鏈接一個詳細的項目，這樣當文件發(fā)生改變時，鏈接的項目就會同時被存儲。

　　還不僅限于此，ASP.NET也存儲輸出數(shù)據(jù)。 為ASP。NET腳本結(jié)果做一個備份，因此當別人調(diào)用它時，他甚至不用運行，正確的輸出結(jié)果就已在發(fā)送中。它主要基于查詢字符串來工作，如果參數(shù)不能與存儲中的參數(shù)相匹配，則記載參數(shù)的頁面會回轉(zhuǎn)到存儲版本中

　　一些時候，依據(jù)站點來判斷出什么需被存儲是有一點技巧，但是至少現(xiàn)在不需要。

　　更快更簡便的開發(fā)

　　任何開發(fā)平臺都會向你提供一個固態(tài)的環(huán)境. 在ASP里,雖然這個環(huán)境的性能是優(yōu)良的,但實際上它亳無用處.但是通過ASP.NET,在你書寫你的第一行代碼前,這個環(huán)已為您做足了準備工作。以前程序員為了設計完善的程序,而不得不做的重復的煩人的工作,現(xiàn)在這個環(huán)境已為你做完了.

　　面向?qū)ο竽Ｐ?br>
　　當你的代碼比以前任何時候都要運行得更快的時候，你已經(jīng)得到一個真正的事件模型并可以對它進行控制。在過去，如果你希望某程序運行的早一些，你就不得不將程序放在頁面的前面，相反，則放在頁面的后部。這種方法往往不會起到很大的作用，所以你還得通過各種方法來構(gòu)建你的代碼以獲得想要的效果. 這個“spaghett-code”問題能夠通過使用大量的事件來修正，例如 page_load

　　每個頁面級的對象都會有它們自己的事件模型，并且有能夠激活設計好的Server事件。類似于 Button_Click 或 Listbox_Change 的例行程序，能夠做出標準的表單處理，以及代你處理大量的相對簡單的日常工作。讀代碼也成為可能，如此就意味著即使某段程序在六個月后出現(xiàn)了問題，也可以發(fā)現(xiàn)你以前的設定，并及時進行調(diào)試。