從ASP到ASP.NET：遷移使用者介面

經驗表明，將使用者介面（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中，儘可能增強可用性及可靠性，因為進程外狀態伺服器並不能帶來顯著的效能優勢。