經驗表明，將用戶界面（UI）從ASP遷移到ASP.NET，性能將提升50~80%。之所以得到這樣的結果，一半的原因是對於大多數良好設計的應用程序來說，惟一未進行原生編譯的就是UI。業務和數據層組件已經是編譯好的DLL，UI通過一個COM接口來調用這些DLL。由於.NET框架提供了與現有COM對象不錯的互操作性，所以較合理的做法就是只將基於ASP的UI層移植到ASP.Net中。
但除了編譯和COM互操作性的好處之外，這樣做還有另外幾個優點:
ASP.Net UI模型
如果開發者以前曾綜合運用Visual Notepad和Visual Interdev來進行編輯，在接觸了ASP.NET的界面後，很快就會被ASP.NET出色的UI構建模型所吸引。微軟通過實現一個新的網頁和控制模型，並模擬VB6的開發思維模式，從而顯著縮短了UI開發時間。網頁模型模擬了Windows消息傳遞模型，並將其分解成Web客戶端和Web服務器兩個部分。更重要的是，ASP.Net服務器控件為開發者賦予了VB6風格的窗體功能，能自動管理需要的狀態，同時不需要開發者的介入。最終的結果是，開發者用少得多的時間就能開發出可靠得多的UI。
ASP.Net還提供了大量預先寫好的控件，並提供了容納它們的一個框架。這些控件包括TextBox、Calendar、Drop-down List Box、TreeVIEw、TabControl等等。服務器控件提供了與ActiveX控件相似的功能，但它們不要求具有相同級別的客戶端配置或權限。注意不是在客戶端上執行二進制代碼，而是在服務器上執行，並生成HTML輸出，以便由客戶端浏覽器使用。另外，如果浏覽器支持，還可生成Html和JScript的一個組合，允許窗體在客戶端上執行，從而盡可能減少Web應用程序所產生的往返行程。
為了將現有的ASP窗體升級到ASP.NET，需要將HTML代碼載入一個新的ASP.NET窗體中，然後操縱HTML源代碼，將控件變成服務器控件。假如窗體中有大量腳本代碼，並利用了Visual Interdev設計器，那麼較容易的做法是運行ASP應用程序，然後在浏覽器中選擇【查看】|【源文件】，剪切並粘貼Html，從而將基本的窗體載入ASP.Net。
可擴展的UI模型
為了真正發揮出ASP.NET的優勢，你不僅要從一個現有的ASP應用程序拷貝Html代碼，還應利用ASP.NET的代碼重用能力，方法是將網頁元素定義成可重用的控件。利用ASP.NET UI模型的擴展能力，你可對常用功能進行分組，並綜合運用新的Page基類、用戶控件以及Web服務器控件來實現新的ASP.Net網頁，並用它取代原始的ASP網頁。例如，公司用戶在使用由公司的不同部門提供的ASP應用程序時，要解決的最困難的問題之一就是如何應付形形色色的UI模型。
如果你的公司打算遷移到ASP.NET，我們的第一個建議是將自行設計的菜單和導航系統替換成網頁類和用戶控件的一個內部ASP.Net實現，或者替換成第三方組件廠商的標准導航實現。
對於第三方導航系統，注意要選擇提供了.NET源代碼的產品，這樣才能建立自己的內部導航標准。通過在所有ASP.Net系統中重用這個實現，你的用戶就能獲得統一的導航機制。另外，還能顯著減少為未來的系統編寫的導航代碼數量。
UI遷移的其他好處
除了UI開發模型所帶來的好處之外，還應全面地利用ASP.NET內建的緩存和會話狀態機制。開發者只需少量工作，即可利用ASP.Net輸出緩存機制，為用戶顯著地改進網頁加載性能。如果需要緩存單獨的對象，或者要對網頁緩存機制進行細致的控制，可利用內建的Cache API來進行更加明確的緩存控制。
除非你實現了自己的專用狀態管理機制，否則經典ASP內建的會話狀態管理不允許應用程序擴展到一台機器的范圍之外。雖然我對“會話管理”的建議保持不變——除非絕對需要，否則不要用它——但使會話狀態跨越多個前端服務器的機制是內建於ASP.Net中的。你既可使用單獨一個狀態服務器，由它將一組Web服務器的狀態存儲到自己的內存中，也可將狀態存儲到一個公共的SQL Server後端。無論選擇哪種機制，都要求在本地Web.Config文件中進行一處簡單的更改。根據我在這兩種機制上的經驗，建議你將狀態數據存儲到SQL Server中，盡可能增強可用性及可靠性，因為進程外狀態服務器並不能帶來顯著的性能優勢。
