ASP.NET超凡的代碼控制(一)

crystal譯·yesky   　　對於COM對象不再需要再在伺服器上註冊的這個功能我們是非常喜愛的。但是通過這種過程簡化，我們也能也許會在不 經意間將一罐蠕蟲開啟。這些惡夢躲藏在DLL背後的一個原因（就象我們憤恨的那樣）即是它加強了版本的保密性。你 再也不能夠在你的伺服器上運行 另外一個DLL版本，並且代碼相當保密，這意味著，如果沒有正確的開發工具和原始碼， 很難改變代碼。 　　這個安全的機制，現在已經刪掉了。你可以在你的伺服器上運行任何你想啟動並執行DLL版本，這些DLL可能會導致各種令 人頭痛的問題和安全方面的噩夢。 　　許多開發人員喜歡COM對象的另一個很大便利之處是，你可以將你的商業邏輯打包，除了開發人員之外，沒人能看到它---- 對象是被編譯過的，因此你的客戶是看不到的。在新的架構裡，你必須得用應用程式來分散源檔案，因為NGWS一定會追蹤 源檔案的軌跡。終端使用者能夠按他們的意願瀏覽或者修改代碼。當然，你也可以將 對象 編譯，或者不給出源檔案，但是 隨之而來的是，你會失去NGWS所提供的一些便利功能，這是得不償失的。 　　你也要密切留意那些進入你檔案的人可能使用的一些源控制之外的東西（例如：Visual Source Safe）。那麼任一用 戶都會相當容易的進入或者修改你的 objects，那麼去想想那些駭客們吧。 　　對於XML來說，這些問題同樣適用。任何人都能輕而易舉黑了你。 　　適應性 　　肯定的是，通常任何一個全新的技術，在市場滲透都會花費一些時間。微軟正在開始讓ASP和IIS平台通過行業驗證， 以便讓其作為其它網路伺服器之外可以供選擇的平台 　　對於在其基本構架上的如此巨大的改變，是很難說服客戶或者開發人員丟棄他們以前所使用的方法而來改用現有的方 法。當然，隨著時間的流逝，問題總是會被慢慢的解決，但事實上，ASP+要被市場接受，所面臨的是一道障礙；即使慢慢 的被採納，尋找高品質解決方案和支援人員方面的問題也會接踵而來。事實上，ASP.net仍然是個alpha 技術，但在尋求支 持方面，它又是如此幸運。 　　現存代碼 　　當然，在將系統轉換成 ASP.net之前，你得將你所有現存的代碼重寫一遍。你的那些舊的代碼仍舊會在IIS內運作，但 你仍然將使用傳統的ASP架構（這不是件壞事）。當然，將一個龐大的web 應用程式移植到ASP.net中是一件非常痛苦的過 程，特別是你已經有大量的解決方案或者說是COM對象。 　　ASP.NET代碼編譯   　　讓我再重申一次:ASP.NET 代碼現在被編譯了.別緊張,這不是象你想的那樣.你不需要建立檔案,為了重新註冊組件不得 不stop 然後restart，現在不需要這樣了，你只需照往常一樣書寫代碼,仍然從早期捆綁中受益，系統會及時進行編譯,