ASP.NET超凡的代码控制
生活随笔
收集整理的這篇文章主要介紹了
ASP.NET超凡的代码控制
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
crystal譯··yesky?
適應性
肯定的是,通常任何一個全新的技術,在市場滲透都會花費一些時間。微軟正在開始讓ASP和IIS平臺通過行業驗證,以便讓其作為其它網絡服務器之外可以供選擇的平臺
對于在其基本構架上的如此巨大的改變,是很難說服客戶或者開發人員丟棄他們以前所使用的方法而來改用現有的方法。當然,隨著時間的流逝,問題總是會被慢慢的解決,但事實上,ASP+要被市場接受,所面臨的是一道障礙;即使慢慢的被采納,尋找高品質解決方案和技術支持方面的問題也會接踵而來。事實上,ASP.net仍然是個alpha 技術,但在尋求支持方面,它又是如此幸運。
現存代碼
當然,在將系統轉換成 ASP.net之前,你得將你所有現存的代碼重寫一遍。你的那些舊的代碼仍舊會在IIS內運作,但你仍然將使用傳統的ASP框架(這不是件壞事)。當然,將一個龐大的web 應用程序移植到ASP.net中是一件非常痛苦的過程,特別是你已經有大量的解決方案或者說是COM對象。
ASP T代碼編譯
讓我再重申一次:ASP.NET 代碼現在被編譯了.別緊張,這不是象你想的那樣.你不需要創建文件,為了重新注冊部件不得不stop 然后restart,現在不需要這樣了,你只需照往常一樣書寫代碼,仍然從早期捆綁中受益,系統會及時進行編譯,
優化和緩沖存儲. 這是怎樣辦到的呢?
根據腳本的首次請求, runtime將代碼進行編譯,并將編譯結果進行高速緩沖存儲復制(備份). 不論何時,只要腳本有請求,被存儲的副本都可以調出使用. 此結果大大的增強了系統性能, 因為在首次請求之后,代碼能更快的從編譯版本中運行.
有人也許就會問了”它怎么知道我什么時候作了改動?” 微軟已對此作出解答.Runtime通過文件系統來監視源文件. 當初始源文件發生改變時,它自動將編譯版本從高速緩沖存儲備份中拖出,因此當下一個要求來臨時,它(編譯文件)會被重新編譯.這就意味著系統會自動編譯代碼, 程序員就再也用不著為人工編譯而頭疼了.
caching
對于多數的系統開發者而言,他們必須研制出一些“caching”來使系統速度加快。無論是ASP頁面輸出到HTML文件格式,網絡聯結速度都非常慢。或是從緩慢的internet鏈接引用,到recordset的 狀態和漫游表單上的email表示符,甚至一個數據庫動態驅動菜單,實際上不是完全的動態驅動,你不能為你每個客戶請求而浪費大量時間。在創建網站時,一般來說,少量數據不會持續改變,但是正因為它們不是真正意義上的動態,不意味著使代碼復雜化,那么它們在哪兒呢?所以,你得開發一些caching
基本的 caching 活動是首先甄選適當的數據進行存儲。然后你需要將它們放置在程序中的application級變量中。然后,識別代碼。然后,你就得決定得將數據存儲多久,并寫出程序,以便及時清空caching.但是,如果你清空了caching的話,那么所使用的程序得具有使數據重新恢復的功能。
在ASP.NET中建立了CACHING系統。使得使得整個系統比以前更為面向對象,使得 caching系統也可以存儲 對象 。因此,無論何時caching,也可以隨時調用。你可以根據需要設置數據存儲的時間來決定創建各種類型的環境。 通過文件系統,你甚至可以在文件上鏈接一個詳細的項目,這樣當文件發生改變時,鏈接的項目就會同時被存儲。
還不僅限于此,ASP.NET也存儲輸出數據。 為ASP。NET腳本結果做一個備份,因此當別人調用它時,他甚至不用運行,正確的輸出結果就已在發送中。它主要基于查詢字符串來工作,如果參數不能與存儲中的參數相匹配,則記載參數的頁面會回轉到存儲版本中
一些時候,依據站點來判斷出什么需被存儲是有一點技巧,但是至少現在不需要。
更快更簡便的開發
任何開發平臺都會向你提供一個固態的環境. 在ASP里,雖然這個環境的性能是優良的,但實際上它亳無用處.但是通過ASP.NET,在你書寫你的第一行代碼前,這個環境已為您做足了準備工作。以前程序員為了設計完善的程序,而不得不做的重復的煩人的工作,現在這個環境已為你做完了.
面向對象模型
當你的代碼比以前任何時候都要運行得更快的時候,你已經得到一個真正的事件模型并可以對它進行控制。在過去,如果你希望某程序運行的早一些,你就不得不將程序放在頁面的前面,相反,則放在頁面的后部。這種方法往往不會起到很大的作用,所以你還得通過各種方法來構建你的代碼以獲得想要的效果. 這個“spaghett-code”問題能夠通過使用大量的事件來修正,例如 page_load
每個頁面級的對象都會有它們自己的事件模型,并且有能夠激活設計好的Server事件。類似于 Button_Click 或 Listbox_Change 的例行程序,能夠做出標準的表單處理,以及代你處理大量的相對簡單的日常工作。讀代碼也成為可能,如此就意味著即使某段程序在六個月后出現了問題,也可以發現你以前的設定,并及時進行調試。
適應性
肯定的是,通常任何一個全新的技術,在市場滲透都會花費一些時間。微軟正在開始讓ASP和IIS平臺通過行業驗證,以便讓其作為其它網絡服務器之外可以供選擇的平臺
對于在其基本構架上的如此巨大的改變,是很難說服客戶或者開發人員丟棄他們以前所使用的方法而來改用現有的方法。當然,隨著時間的流逝,問題總是會被慢慢的解決,但事實上,ASP+要被市場接受,所面臨的是一道障礙;即使慢慢的被采納,尋找高品質解決方案和技術支持方面的問題也會接踵而來。事實上,ASP.net仍然是個alpha 技術,但在尋求支持方面,它又是如此幸運。
現存代碼
當然,在將系統轉換成 ASP.net之前,你得將你所有現存的代碼重寫一遍。你的那些舊的代碼仍舊會在IIS內運作,但你仍然將使用傳統的ASP框架(這不是件壞事)。當然,將一個龐大的web 應用程序移植到ASP.net中是一件非常痛苦的過程,特別是你已經有大量的解決方案或者說是COM對象。
ASP T代碼編譯
讓我再重申一次:ASP.NET 代碼現在被編譯了.別緊張,這不是象你想的那樣.你不需要創建文件,為了重新注冊部件不得不stop 然后restart,現在不需要這樣了,你只需照往常一樣書寫代碼,仍然從早期捆綁中受益,系統會及時進行編譯,
優化和緩沖存儲. 這是怎樣辦到的呢?
根據腳本的首次請求, runtime將代碼進行編譯,并將編譯結果進行高速緩沖存儲復制(備份). 不論何時,只要腳本有請求,被存儲的副本都可以調出使用. 此結果大大的增強了系統性能, 因為在首次請求之后,代碼能更快的從編譯版本中運行.
有人也許就會問了”它怎么知道我什么時候作了改動?” 微軟已對此作出解答.Runtime通過文件系統來監視源文件. 當初始源文件發生改變時,它自動將編譯版本從高速緩沖存儲備份中拖出,因此當下一個要求來臨時,它(編譯文件)會被重新編譯.這就意味著系統會自動編譯代碼, 程序員就再也用不著為人工編譯而頭疼了.
caching
對于多數的系統開發者而言,他們必須研制出一些“caching”來使系統速度加快。無論是ASP頁面輸出到HTML文件格式,網絡聯結速度都非常慢。或是從緩慢的internet鏈接引用,到recordset的 狀態和漫游表單上的email表示符,甚至一個數據庫動態驅動菜單,實際上不是完全的動態驅動,你不能為你每個客戶請求而浪費大量時間。在創建網站時,一般來說,少量數據不會持續改變,但是正因為它們不是真正意義上的動態,不意味著使代碼復雜化,那么它們在哪兒呢?所以,你得開發一些caching
基本的 caching 活動是首先甄選適當的數據進行存儲。然后你需要將它們放置在程序中的application級變量中。然后,識別代碼。然后,你就得決定得將數據存儲多久,并寫出程序,以便及時清空caching.但是,如果你清空了caching的話,那么所使用的程序得具有使數據重新恢復的功能。
在ASP.NET中建立了CACHING系統。使得使得整個系統比以前更為面向對象,使得 caching系統也可以存儲 對象 。因此,無論何時caching,也可以隨時調用。你可以根據需要設置數據存儲的時間來決定創建各種類型的環境。 通過文件系統,你甚至可以在文件上鏈接一個詳細的項目,這樣當文件發生改變時,鏈接的項目就會同時被存儲。
還不僅限于此,ASP.NET也存儲輸出數據。 為ASP。NET腳本結果做一個備份,因此當別人調用它時,他甚至不用運行,正確的輸出結果就已在發送中。它主要基于查詢字符串來工作,如果參數不能與存儲中的參數相匹配,則記載參數的頁面會回轉到存儲版本中
一些時候,依據站點來判斷出什么需被存儲是有一點技巧,但是至少現在不需要。
更快更簡便的開發
任何開發平臺都會向你提供一個固態的環境. 在ASP里,雖然這個環境的性能是優良的,但實際上它亳無用處.但是通過ASP.NET,在你書寫你的第一行代碼前,這個環境已為您做足了準備工作。以前程序員為了設計完善的程序,而不得不做的重復的煩人的工作,現在這個環境已為你做完了.
面向對象模型
當你的代碼比以前任何時候都要運行得更快的時候,你已經得到一個真正的事件模型并可以對它進行控制。在過去,如果你希望某程序運行的早一些,你就不得不將程序放在頁面的前面,相反,則放在頁面的后部。這種方法往往不會起到很大的作用,所以你還得通過各種方法來構建你的代碼以獲得想要的效果. 這個“spaghett-code”問題能夠通過使用大量的事件來修正,例如 page_load
每個頁面級的對象都會有它們自己的事件模型,并且有能夠激活設計好的Server事件。類似于 Button_Click 或 Listbox_Change 的例行程序,能夠做出標準的表單處理,以及代你處理大量的相對簡單的日常工作。讀代碼也成為可能,如此就意味著即使某段程序在六個月后出現了問題,也可以發現你以前的設定,并及時進行調試。
總結
以上是生活随笔為你收集整理的ASP.NET超凡的代码控制的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 在网页中动态的生成一个gif图片
- 下一篇: ASP.NET强大的性能