ASP.NET 打造互聯(lián)網(wǎng)未來空間站(2)

帶有"/scott" URL，實際上被ASP.NET轉(zhuǎn)換成他要去的地方，是嗎？
是的，因此在實際運行前，你會有一些代碼解析"/scott" 部分，轉(zhuǎn)換成一個實際地址的頁面，實際執(zhí)行的是一個很普通的頁面。這種方式可以使得所有的用戶都得到個性化。我們有一個模塊中的一個API可以為你解決這個問題。在這個問題上，我們也有一個擴展點。在ASP的時候，我們有一個叫做Global.asa的概念，他可以定義應用開始，應用結束，Session 開始，Session結束等事件。在ASP.NET中我們允許您將ISAPI過濾器功能加入Global.asa中，因此，如果您想繼續(xù)重定向URL時候，你甚至不需要寫一個模塊了，你只需要在Global.asa中定義就足夠了。
我們做的另一點是，努力提高安全水平并且允許更為靈活的認證，在過去，您使用ASP的時候，您主要用IIS來構建您的認證功能，這種認證實際上依賴NT SAM，在ASP.NET中，我們將安全模塊放入ISAPI過濾器中，因此如果您想在一個main frame 或者在你有一些usernames/passwords的數(shù)據(jù)庫中，并且是你自己做這種認證時，你可以在Global.asa中寫入相關的信息或者在一個與那個事件同步的組件中加入相關信息。
因此，我可孕匆桓鑫易約河沒�名的数据匡喫，并沁b�他还带有标准的痊F(xiàn)す�倡H?BR>是的，沒錯。如果你這樣做了，你可以獲得更多的東西，你不僅可以擁有了用戶名字和口令，而且還會有角色（role）這樣的東西。你可以將那些用戶映射成角色，你可以使用這種方式而不是僅僅使用ACL的方式構建你的站點。你可以知道Joe 和 Mark（用戶名）訪問了這個頁面，相反，你也可以知道這個頁面被哪個角色訪問了。你在數(shù)據(jù)庫的主要工作就是告訴我們 Mark 的用戶名和密碼是什么，他在哪一組角色中，其余的工作由安全系統(tǒng)來考慮，以保證它可以訪問那些網(wǎng)頁或者服務。當然，這里需要提及的是，所有的架構，安全架構、caching架構都為網(wǎng)頁和XML服務提供支持。
如果從性能角度來看，增加的這些東西，這些能力，可以提供更好的性能服務嗎？
我們的確提供了更好的性能服務，當我們創(chuàng)建ASP.NET項目組時，我們就指定一個開發(fā)人員專門負責性能上的工作，我們當時使用的是早期的common language runtime，他每日的工作就是檢查每項操作是變快了還是變慢了，并且與運行時(runtime)項目組一起查找問題，加速變慢了的操作。同時，他也指出性能上的問題。這樣做的結果是ASP.NET比ASP要更快。所有的代碼都是編譯過的，編譯成本地代碼，不再用解釋的方式。
是嗎，那么說我在ASP.NET中寫的程序代碼再也不用解釋的方式？
正確。此外，更好的是，您仍然可以像您從前那樣在編輯器里面編寫代碼，點擊SAVE存盤，然后剩下的事情都交給系統(tǒng)去處理。但是，對于剩下工作ASP與ASP.NET確有不同處理方式。ASP采用的是分析代碼然后傳給腳本引擎，在程序運行時解釋代碼；而ASP.NET則是傳給編譯器，然后在common language runtime上運行。在common language runtime上執(zhí)行的是本地代碼，因此你可以用VB編制程序獲得與C++一樣級別的性能。
那么，它是在什么時候編譯，是在我存儲文件并且NT文件系統(tǒng)發(fā)現(xiàn)文件變化時，還是頁面第一次使用的時候？
當某人請求頁面的時候發(fā)生。我們將會檢查，是否某個頁面已經(jīng)被編譯，如果沒有編譯，我們將會編譯他。我們在ASP.NET中作了許多很有趣的工作，使得編譯過程更有效率。因為我們編譯了他，所以如果你為了使機器更可靠或者性能更好而重起機器或者shut down你的WEB服務器或者shut down你的進程時，你不用再編譯你的那個頁面了，因為我們已經(jīng)檢測到了該文件已經(jīng)被編譯和加載，這樣可以獲得更高的響應速度和更強的伸縮性，并且那也是因為把它放在CACHE的某個地方了。

下面我們在談論一下性能。好，我們談論一下性能，是的，從整體上看，性能是更優(yōu)化了。我們也在可擴展性，可靠性，可獲取性方面作了很多的工作。我們曾經(jīng)有一個假設，在一個common language runtime上，即使有一個Session想要和所有與他相關的東西通信的話，應用程序的可靠性仍然變得很高。
我們還可以舉些例子。例如，真正強大的類型檢查。在一個可管理的環(huán)境中，如果出現(xiàn)數(shù)組越界的情況，系統(tǒng)將會拋出一個exception而不會產(chǎn)生一個垃圾內(nèi)存。除此之外，我們還有更多的可靠性機制保證您的使用。例如，我們可以檢測內(nèi)存沖突，也就是內(nèi)存在某一點徘徊。我們可以檢測到死鎖，你甚至可以配置系統(tǒng)以便在發(fā)生這樣的情況的時候，你的機器可以每隔多長時間重起一次。因此，在出現(xiàn)這樣的情況的時候，我們可以規(guī)定一小時一次、一天一次或者每隔200個請求一次等來啟動一個應用程序的新的實例。然后允許舊的應用程序完成相關的任務后，新的程序接著進行。
保持這樣的一個可靠性機制使得你不必中斷任何為用戶工作的服務。我們將會動態(tài)地生成一個新的進程，開始接受新的請求，老的進程完成當前運行的所有請求，然后我們將刪除老的進程。在這樣的過程中，為了提高效率，系統(tǒng)實際上作了RESET的工作。但是這個過程中，你不會看見管理人員的干涉。你的客戶也不會感覺到任何變化，他們會認為，嗷，每一件事情都運行的這樣好，服務器還在運行。用這樣的方式，你就可以獲得非常高的可靠性。
此外，我們在Session State上也有了一些改進，Session State不再需要和你的代碼運行在同一個進程中。他可以作為一種服務運行在一臺機器上，也可以作為一種服務運行在整個WEB服務器群中的某一臺機器上，其他的前端機器可以共享該服務。

Session State只能存放在一臺機器上嗎？
不，不是的，如果需要的話可以在多臺機器上保留。Session State可以在多臺機器上存儲，也可以有多臺機器的前端去訪問那些存儲信息。

我是一個用戶，我正在訪問一臺機器，我的Session State留在這臺機器上，如果我下一次要訪問另一臺機器，Session State中的數(shù)據(jù)可以共享嗎？
是的，這種工作方式是WEB群組最典型的工作方式。一個用戶你可以訪問機器A，等一會兒，你又會訪問機器B，你的Session State保留在另外一臺獨立的機器上。Session State既可以運行在我們的Session State provider上面也可以運行在SQL Server上面，我們有一種方式可以讓SQL Server成為Session信息的服務器。但是，前端的這兩臺機器，也可以是多臺機器，都可以訪問同樣的Session State。

這樣看來，我們可以通過這種方式共享數(shù)據(jù)了。
是的，正確。但是你可以想象一旦你擁有這種Session State,與你的ASP代碼不在一個進程中運行的Session State，無論你的ASP程序遇到下面什么樣的問題，程序崩潰、我們終止了你的代碼運行、我們檢測到某種資源漏洞或者鎖定、我們所配置的一些事情（例如一小時一次）遇到問題時，你所有的Session依然是安全的。因為，你將你的Session State保存在另外一臺獨立的機器上了。
如果你只有一臺機器，你也可以利用Session State的這種特點，你可以讓他運行的進程與你的代碼運行的進程不同，因此，只要進程到來時，他們就可以訪問在安全保護進程中的Session State。
正如我們剛才提到的，Session State最重要的幾個好處是：（1）可靠性。你不用再擔心你的應用程序崩潰或者一個用戶數(shù)據(jù)丟失這樣的事情發(fā)生。（2）第二個好處是，現(xiàn)在，你的應用程序不必再局限于一臺機器。如果你使用了Session State ，你的確可以將你的應用擴展到更多臺的機器上，這樣，就真的沒有什么條件能夠限制你了，也就是說，你不必再擔心你的應用程序能夠在多大范圍內(nèi)或者能夠為多少用戶提供正常服務這樣的問題。
聽了上面的講解，我們好像做了兩種不同的事情，一個是ASP.NET提供了許多新的功能和性能，人們可以充分利用這些新的特點；另外一個方面是，在這些功能和性能的后面，ASP.NET做了許多額外的工作，使得這些特征和功能發(fā)揮了更大的作用。
是這樣的

對我來說，如果我已經(jīng)有了一個ASP的WEB站點，如果他已經(jīng)為我提供了滿意的結果，我不想再改變程序中的任何東西，如果我將站點的整個框架更新到新的ASP.NET上或者類似的東西上，那么就意味著我的站點獲得更多的魯棒性。
是這樣的，你說的的確是一個很有趣的觀點。我確信，如果你是那個用戶，你說那個站點的應用程序運行良好，我的確不想做任何改變，如果我需要升級到ASP.NET框架的時候，我只想在我的機器上安裝這個ASP.NET即可。如果你這樣做了，我們并不會替換你的機器上任何的ASP代碼，因此ASP與ASP.NET運行在一臺機器上。但是，你實際上將不得不將運行環(huán)境讓位給ASP.NET，并且重新配置你的機器。盡管作這樣的事情沒有什么難的，但是你需要告訴我們你想讓ASP.NET運行ASP的那些程序。因為，如果一個機器里已經(jīng)存在了多個應用程序的時候，你再想安裝一個新的運行環(huán)境，新的編譯環(huán)境，和所有新的.NET的那些東西時，我們不能完全保證你的每個應用程序在升級后的環(huán)境中都運行良好，都帶給你同樣的性能。做服務器程序的開發(fā)人員將會用很長的時間調(diào)試他們的程序，以確保程序正常工作。
如果我是按照你們說的去做，那么，好，我安裝了ASP.NET，我標記了我的文件，并且告訴他們：現(xiàn)在你們運行在ASP.NET的環(huán)境中，就算是我根本沒有對文件作任何改變，我是否可以獲得具有更高魯棒性和更好柔韌性的解決方案？
是的，你將獲得具有更高魯棒性和更好柔韌性的解決方案。不過，在這里我要提及的一個重要的事情是，我們當前的解決方案不是百分之百地與ASP兼容。眾所周知，盡管我們的ASP.NET與ASP之間具有非常非常的親密關系，但是，最近幾年里，當我們開發(fā)這個平臺的時候，由于若干的總總原因，我們不得不犧牲一些兼容性。但是人們根本不會感覺到這些。在ASP.NET中，我們獲得COOKIES的順序?qū)嶋H上稍稍發(fā)生了一些變化。這一切正如我們期望的那樣，不會有百分之百的兼容。不過最重要的是，無論發(fā)生了怎樣的變化，如果你安裝了ASP.NET后，你現(xiàn)有的代碼和你現(xiàn)有的網(wǎng)頁將依然會正常的工作。
從整體上看ASP.NET對你是有幫助的，但是由于它本身的一些小小的變化，你將不得不隨之作一些小小的調(diào)整。我們會有一些自動化的工具幫助你完成這一切。但是，對于大型的應用來講，毫無疑問，你要做一些改變。

讓我們再一次回顧一下理解你的應用程序架構的一些關鍵的事情或者簡單看看那些新的事物
很好，這是一個很有意思的部分。這其實是一種移植工作。你可以將一個頁面，將你所掌握的技巧，將你能夠你所做的一切，將你寫的東西移植到ASP.NET上，你依然可以用同樣的技巧，同樣的技術，但是你將獲得更高的性能。當人們開始了解這個平臺的時候，我推薦給人們的是應該了解這個平臺的所有特征。因為除了移植外，還有很多的新的特征。也可能不僅僅是移植的過程還有一點點重建的過程。例如，我們在前面提到了確認的過程，大多數(shù)的應用程序都可以用到不同程度的確認過程。但是，他將不再是“保留你原來的確認邏輯，并且讓他運行的更快一些”，而是，完全被我們的確認組件所替代。
許多人都已經(jīng)用ASP建立了他們自己的某種安全架構，他們可以用它來驗證登錄信息�，F(xiàn)在當他們知道ASP.NET帶有這種功能是，他們會說，這下可好了，我可以直接使用ASP.NET內(nèi)嵌的認證功能了，在也不用我自己編的那些東西，不再用Session State跟蹤用戶信息。
Caching是與性能相關的的一項重要的功能，我前面沒有提及，許多的開發(fā)人員非常努力并且使用了很多的非常好的技術試圖弄明白一個頁面的局部或者服務器上的整個一個頁面的運行結果，以便當兩個瀏覽器請求同一個特殊資源時，不必重新生成兩次，我只要使用cache中的版本就可以了。在ASP.NET中，我們提供了一個對cache的支持。
我想說的基本也就這些，但是我認為他們是值得花時間的，特別是你想快速開始時，在SDK中，我們有大約900來個例子，這是一個很大的數(shù)目，我們有一些很大的端到端的應用程序，一個電子商務的應用，一個建立類似INTRANET門戶框架的應用。我認為，認真研究這些應用程序，并且看看他們是如何構建的是一件很值得做的事情。因為你會發(fā)現(xiàn)你找到了很多技巧，意想不到地減少了你寫代碼的數(shù)量。使你的代碼更干凈。我想，你將會突然發(fā)現(xiàn)那些的確難以管理的50、60行的代碼變成了5、6行清晰的代碼，幾周之后，你再回來看看時，一目了然。很容易弄清楚是什么意思。

小結：
關于ASP.NET最重要的事情是，首先，他使得開發(fā)人員的效率大大地提高了。他使得應用程序和系統(tǒng)的可靠性大大地增強了，有許多東西使得應用程序真的很容易配置。例如，當你的應用程序正在運行時，如果你復制一個DLL時，他沒有被鎖定，這樣你的應用程序就可以平滑地移植到新版本上。舉這個例子是為了說明可以真正地提高性能、可靠性、可用性、可擴展性。我想，所有這些能力都實際上是系統(tǒng)中最重要的事情。除此之外，我們還增加了大量的新的功能。我知道有很多的人看著ASP從1.0，2。0，到3.0成長的，他們今天看到ASP.NET時候會說，嗷，對于server對象或者response 對象以及其他類似的東西還有三種不同的方法。這就是新特征帶給我們的巨大的財富。