.NET Framework環境下的ASP網頁製作

来源：互联网发布：网络外卖加盟店排行榜编辑：程序博客网时间：2024/04/30 07:20

網路公司裁員、網站關閉、電子報停刊…，經歷電子商務的退潮之後，有人開始質疑電子商務是不是被高估了。也許網際網路不再編織賺大錢的美夢，但經過這幾年的洗禮，網際網路已經成為大眾生活中的一部份，據說台北市的國中生能製作網頁者已經相當普遍，由此可見一斑，當網頁製作變成一般知識之後，想生存於網際網路，夠不夠專業將是決勝因素。

在 .NET Framework底下，筆者很欣慰ASP(Active Server Pages)變得更專業了，簡單地回顧過去的ASP，我們至少可以指出幾個缺點：

只能使用VB Script或Java Script這兩種程式語言來開發ASP。
沒有好的偵錯程式(Debugger)。
網頁結構會隨著程式變大而一團亂。
ADO無法直接與DataGrid元件結合。

本期筆者將為您解說ASP的新面貌(微軟把這個新的ASP稱為ASP.NET)。

從ASP到ASP.NET

ASP會變得很紅，恐怕連微軟也覺得意外，因為ASP一直都附屬於IIS，算不上獨立的產品。IIS版本與ASP版本的對應如下：
IIS 版本附帶在 IIS 底下的 ASP 版本IIS 3.0ASP 1.0IIS 4.0ASP 2.0IIS 5.0ASP 3.0
有人會用1.0、2.0、3.0來區分ASP的版本，但筆者不以為然，因為從ASP 1.0版到3.0版，微軟並沒有花太多心思來改良ASP，只是因為IIS改版了，所以ASP也跟著做微幅的改版，因此從ASP 1.0版到3.0版，在功能上並沒有顯著的改變，所以不管ASP 1.0、2.0或3.0，筆者都叫它們ASP。
隨著ASP的使用者越來越多，希望ASP更好的聲音也越來越強烈，也許是從善如流，也許是為了推廣 .NET Framework，微軟針對ASP的使用者做了市場調查，找出ASP必須改良的地方，而發展了下一代的ASP，也就是ASP.NET(或者稱為ASP+)。

ASP.NET與ASP的相容性

從ASP升級到ASP.NET，大家最擔心的問題可能是「會不會影響既有ASP網頁的咦鳌梗P者將ASP作業平台升級到ASP.NET作業平台之後(本文撰寫時所安裝的ASP.NET版本是Beta 1)，還沒有發現既有的ASP網頁不能咦骰虮仨毿薷牡摹?/P>
在實際咦魃希擜SP網頁(以 .ASP為副檔名)被瀏覽時，IIS會啟動ASP.dll來執行ASP網頁，而當ASP.NET網頁(以 .ASPx為副檔名)被瀏覽時，IIS則會啟動xspwp.exe來執行ASP.NET網頁，兩者的執行檔案不同，因此不只是安裝ASP.NET之後，不會影響既有ASP網頁的咦鳎瑢嶋H上ASP網頁及ASP.NET網頁是並存的。
另一個常問的問題是：需要將現有的ASP網頁轉換成ASP.NET網頁嗎？由於ASP網頁及ASP.NET網頁是並存的，因此咦鞯煤茼樌腁SP網頁可以暫時不必修改，至於哪些網頁必須採用ASP.NET？以下是筆者的建議：
希望效能更高時：當ASP.NET網頁第一次被瀏覽時，Server會先將其編譯成MSIL(Microsoft Intermediate Language)，並且儲存下來，而再度被瀏覽時，即不再重新編譯(除非 .ASPx檔案的內容有所改變)，因此可以提升不少效能。此外，ASP.NET還具備網頁及資料Cache功能(見稍後介紹)，亦可提昇網頁的回應速度。
需要經常維護或修改的網頁：由於ASP.NET採用VB7為程式語言，具備完整的物件導向功能，有助於網頁的維護。
未來新開發的網頁：既然ASP.NET功能優於ASP，未來開發的網頁當然要採用ASP.NET。

程式語言的改變

從ASP到ASP.NET，其中的改變相當多，不過與ASP網頁製作者最有切身關係的應該是程式語言的改變，ASP只接受VB Script及Java Script兩種程式語言，但是對ASP.NET來說，舉凡可以編譯成MSIL的程式語言，都是 ASP.NET可以接受的程式語言。
筆者在Run!PC前3期的「.NET Framework -- 微軟新一代的軟體開發環境」一文中介紹過MSIL，它是一種中介語言，介於高階程式語言(例如VB)及機器碼之間的語言，在ASP.NET底下，我們撰寫的程式語言也會先編譯成MSIL，然後MSIL再被編譯成機器碼加以執行，過程如圖-1，ASP.NET也是採用此一模式，除了會輸出資料到瀏覽器之外，ASP.NET網頁與其他的程式語言的工作模式都是相同的。

圖-1 ASP.NET 網頁編譯執行的過程

執行效能的質疑

第一次接觸ASP.NET網頁的人可能會有這樣的疑問：「執行效能好像不如ASP網頁？」，關於這個問題，讓筆者從咦髂Ｊ絹碚勂穑紫日埧磮D-2，可看出ASP.NET網頁比ASP網頁要多一次的編譯工作。

圖-2 ASP與ASP.NET咦髂Ｊ降谋容^
儘管ASP.NET比ASP網頁多一次的編譯工作，但這並不表示ASP.NET的執行效能一定比較差，參考圖-2，ASP.NET階段二的編譯執行速度優於ASP，但ASP.NET階段一的編譯速度卻慢於ASP，簡單地說，ASP.NET階段一及階段二合起來的時間＞ASP執行的時間。
如果從以上的比較來看，ASP.NET確實比ASP慢，但是請再把網頁的瀏覽分成以下兩種情況：(1) 網頁第一次被瀏覽 (2) 網頁第二次被瀏覽，如圖-3，ASP.NET 網頁第一次被瀏覽時，會經過兩階段的編譯，所以速度較慢，但第一次被瀏覽之後，MSIL會被儲存下來，所以當同一網頁第二次被瀏覽時，只須花費從MSIL編譯成機器碼然後執行的時間，結果比ASP網頁來的快，整體的比較如下：(＞表示較快)

ASP.NET 網頁第二次被瀏覽＞ ASP網頁＞ ASP.NET 網頁第一次被瀏覽

圖-3 第一次瀏覽及第二次瀏覽的差異

.NET Framework 物件類別的使用

微軟宣稱 .NET Framework有許多好處，但筆者最看重的是 .NET Framework所提供的物件類別，.NET Framework所提供的物件類別多達數百種，包含資料結構、資料庫、繪圖、網路、XML、執行緒、目錄服務、安全性…等，應有盡有。
以往ASP網頁雖然可以使用ActiveX物件，但其實只限定於ActiveX物件中的ActiveX DLL，不像一般應用程式(例如VB程式、C++程式)可以同時使用ActiveX DLL、ActiveX EXE及ActiveX Component等多種ActiveX物件，不過這個現象在 .NET Framework底下已經有所改善，在 .NET Framework所提供的物件類別中，除了少數與螢幕輸出有關的物件類別(例如WinForm及Console)是ASP.NET網頁所不可使用之外，其他物件類別則都是ASP.NET網頁可以使用的。
註：WinForm包含windows(視窗)相關的物件類別、Console則是DOS文字輸出模式的物件類別，對ASP.NET來說，其輸出之標的為瀏覽器，所以不可以輸出資料到Windows視窗及DOS文字視窗，ASP.NET專用的輸出物件類別稱為WebForm，則是Windows應用程式不可使用的。

WebForm與Server控制元件

在ASP的網頁製作中，如果我們想設計一個輸入表單(Form)，大概只能使用HTML輸入欄位(或稱為控制元件)，ASP.NET在這方面做了很大的加強，在其WebForm裡面，我們可以佈置各種控制元件(統稱Server控制元件)，這些控制元件包含：
Server控制元件功能CheckBox、CheckBoxList加強HTML核取方塊的功能RadioButton、 RadioButtonList加強HTML選擇鈕的功能TextBox加強HTML文字輸入方塊的功能ListBox 、DropDownList加強HTML下拉式選單的功能Table、TableRow、TableCell加強HTML表格的功能Label加強HTML文字的功能Image、 ImageButton加強HTML圖片的功能LinkButton、 HyperLink加強HTML連結的功能Panel可將控制元件分成多個區塊AdRotator廣告迴旋板Calendar日期的顯示及選擇資料驗證類控制元件可在不必撰寫程式的情況，幫我們驗證使用者所輸入的資料是否正確DataGrid、DataList、Repeater資料庫的顯示
除了提供更豐富的控制元件之外，WebForm的另一個優點是可以記錄網頁的狀態，以往在ASP網頁中，若要記錄Client端的狀態，必須使用Session或Cookie物件，但不管是Session或Cookie物件，都必須在上網者開啟瀏覽器的Cookie功能之下方可咦鳎珹SP.NET改善了此一現象，只要我們將Server控制元件佈置在WebForm之中，WebForm就會記錄所有Server控制元件的狀態(例如控制元件中所輸入的文字)。
記錄控制元件狀態的能力，以須分成多次輸入的表單最為方便，以圖-4的輸入表單為例，若使用ASP的設計，在步驟一及步驟二所輸入的資料必須記錄在Session或Cookie物件中，供步驟三讀取，但是對ASP.NET網頁，只要將步驟一、步驟二、步驟三的Server控制元件佈置在同一個WebForm之中，則不管網頁執行到哪一個步驟，都可以讀取上網者在Server控制元件中所輸入的資料。

圖-4 分成多次輸入的表單

ADO+與資料控制元件

.NET Framework所提供的資料庫存取物件稱為ADO+(Active Data Object+)，雖然有不少觀念與ADO相類似，但卻是全新的物件，為什麼已經有ADO了，還要再提供ADO+呢？筆者覺得原因可能有幾：
採用XML做為資料交換格式：由於XML已經成為網際網路交換資料的標準，這是個不得不的舉動。
延伸資料的範圍：在ADO底下，任何資料都必須透過OLD DB或ODBC來存取，ADO+ 並無此一限制，任何程式都可以藉助ADO+ 所提供的物件讓自己成為新資料格式的提供者，這因此延伸了可存取之資料的範圍。
與資料控制元件的整合：以往我們撰寫ASP網頁時，最不方便的地方是資料庫內容的顯示，為了顯示資料庫的內容，大概必須藉助ADO的Recordset物件逐筆讀取資料錄，然後再逐筆將其顯示出來，程式較冗長，在ASP.NET網頁中，我們只要佈置好DataGrid、DataList或Repeater這一類資料控制元件，然後與ADO+ 進行繫結，DataGrid等控制元件就會自動顯示資料庫的內容。參閱圖-5及圖-6就是分別使用DataGrid及DataList控制元件顯示資料庫內容的網頁。

圖-5 ASPx/ch01/ASPxPage.ASPx">http://www.kjedu.com.tw/kjASPx/ch01/ASPxPage.ASPx 網頁

圖-6 ASPx/ch01/DataList.ASPx">http://www.kjedu.com.tw/kjASPx/ch01/DataList.ASPx

Cache與效能的提升

為了提升執行效能，ASP.NET網頁會先被編譯成MSIL儲存在硬碟中，而下次當該網頁再度被瀏覽時，就可以直接執行被儲存下來的MSIL(細節請參閱「執行效能的質疑」段落的說明)，除了此一強化執行效能的動作之外，ASP.NET所提供的Cache(快取記憶體)功能亦可提升執行效能。ASP.NET提供的Cache功能分成Output Cache及Data Cache兩種。

Output Cache與網頁快取

圖-7 Output Cache與網頁快取

參閱圖-7，所謂Output Cache，是在執行MSIL之後，先將結果寫入Output Cache，然後再將Output Cache下傳到瀏覽器，而將來如果瀏覽同一網頁，ASP.NET會先判斷該網頁是否有Output Cache存在，如果有，則直接將Output Cache下傳到瀏覽器，不會經過編譯 .ASPx及執行MSIL的過程，故能提升執行效能。
要啟用Output Cache的方法十分簡單，只要在 .ASPx網頁的最前面加上以下標示即可：
<%@ OutputCache Duration="秒數" %>
其中Duration表示Output Cache保留在系統中的秒數，例如：
<%@ OutputCache Duration="10" %>
結果網頁的Output Cache將會保留在系統中10秒鐘，而凡是在這10秒內瀏覽此一網頁，ASP.NET就會直接將Output Cache下傳給瀏覽器，省略了編譯的動作。

Data Cache與資料快取

除了將整個網頁儲存於Output Cache之外，我們也可以將局部資料儲存於Data Cache(以下簡稱Cache)。Cache的用法與Application物件很類似，例如：
' 將資料或物件存放在Application物件中
Application("key1") = "這是字串"
Application("key2") = obj

' 將資料或物件存放在Data Cache中
Cache("key1") = "這是字串"
Cache("key2") = obj
不過筆者必須說明的是Data Cache所佔用的記憶體隨時可能會被釋放(視系統記憶體當時使用的情況)，所以每當我們要讀取Data Cache時，要先判斷Cache("key") 是否等於Nothing，若不等於Nothing，表示Cache("key") 還存在於系統中，方可讀取。

提供偵錯工具

在撰寫程式的過程中，難免會有錯誤產生，如何除錯對任何一個程式設計師來說，都是很重要而且是無可避免的工作。ASP的偵錯工具十分欠缺，為了改善此一缺失，ASP.NET提供以下幾種偵錯方法：
設定config.web的customerrors節區
使用追蹤(Trace)功能
偵錯工具程式(Debugger)

設定config.web的customerrors節區

當網頁產生錯誤而無法進一步編譯或執行時，ASP.NET會顯示如圖-8之畫面，此一畫面只告訴我們程式有錯，至於哪一行程式錯誤，則未顯示。為了讓ASP.NET顯示進一步的錯誤訊息，可在config.web檔案中增加customerrors節區的設定，如下：
<configuration>
<customerrors mode="off"/>
</configuration>
結果瀏覽之後可看到更詳細的錯誤指示畫面(如圖-9)
圖-8 ASP.NET網頁編譯或執行錯誤的畫面 (圖略)
圖-9 ASP.NET網頁編譯或執行錯誤的畫面(錯誤訊息較詳細)(圖略)

使用Trace追蹤功能

所謂Trace功能是在網頁的最前面加上以下標示：
<%@ Page Trace="True" %>
結果網頁被瀏覽之後，將會額外顯示一些資訊，如圖-10，而這些資訊有助於我們研判程式的狀況，做為偵錯時的參考。
圖-10 Trace功能啟用之後的網頁(圖略)
在圖-10畫面中，除了網頁正常顯示的內容之外，額外顯示的資訊可分成以下區段：
Request Details：透過Request方式向瀏覽器所讀取之資料。
Trace Information：事件發生或程式執行的過程。
Control Tree：網頁所使用之控制元件及控制元件之間的階層關係。
Cookies Collection：網頁所使用的Cookie。
Headers Collection：瀏覽器的表頭資訊。
Server Variables：Server變數，也就是我們可以透過Request. ServerVariables() 所讀取的資訊。
除了讓ASP.NET自動顯示以上訊息之外，我們也可以將程式執行過程中的資料顯示在Trace Information區段中，方法是呼叫Trace.Write或Trace.Warn，例如：
Trace.Write("UploadFile()", "進入UploadFile事件程序")
Trace.Warn ("UploadFile()", "進入For迴圈")
結果可將訊息輸出到Trace Information區段，供我們做為偵測程式的參考。

偵錯工具程式(Debugger)

ASP.NET提供的Debugger程式很像VB的操作介面，可以讓我們設定中斷點、逐步執行程式、觀察變數及堆疊的情況…等，是偵錯的利器。使用Debugger之前，須在config.web檔案中增加以下的設定：
<compilation debugmode="true"/>
接下來啟動C:Program FilesMicrosoft.NET FrameworkSDKGuiDebug目錄的DbgUrt.exe，然後利用以下步驟即可偵測 .ASPx網頁：
1. 選取DbgUrt.exe功能表的「Debug -> Processes」，待出現「Processes」交談窗時，核取「Show system processes」及「Show processes in all sessions」，然後在「Available processes」欄位的最下面找到xspwp.exe(註：如果沒有看到xspwp.exe，請先啟動瀏覽器瀏覽任意 .ASPx網頁，然後再按下「Refresh」鈕)，選取之後，再按下「Attach」鈕，過程如圖-11。
圖-11 DbgUrt.exe的「Process」交談窗(圖略)
2. 接下來會出現「Attach to process」交談窗(如圖-12)，請按下「OK」鈕。
圖-12 Attach to process 交談窗(圖略)
3. 接下來回到步驟1的「Processes」交談窗，請按下「Close」鈕。
4. 選取DbgUrt.exe功能表的「File -> Open -> File」選取您想偵測的 .ASPx檔案，在此您可以選取多個想要偵測的檔案。

物件的開發

由於ASP.NET以VB7為程式語言，所以VB7所有物件導向的功能也都能夠發揮在ASP.NET網頁製作中，而除了程式語言所提供物件導向功能之外，ASP.NET可以開發一種網頁專用的物件 -- pagelet(網頁小配件)。
何謂Pagelet(網頁配件)？以生活中的實例來看，當我們裝飾耶誕樹時，往往會買些小配件，然後將它們佈置在喜歡的位置，Pagelet的觀念也是相類似的，某些常用的配件，我們可以將它們設計Pagelet，讓其他網頁來使用，舉個更實際的例子，例如我們網頁中佈置一個Label控制元件及一個TextBox控制元件，其作用就是在網頁中插入了一個Label類型的Pagelet及一個TextBox類型的Pagelet。
本文讓筆者先展示一個簡單的Pagelet，此一Pagelet命名為Footer.ascx，如下：(註：Pagelet須以 .ascx 為副檔名)
<Div align="right">
<Hr>
<A href="http://www.kj.com.tw" target="_top">
學 Visual Basic 找王國榮</A>
</Div>
檢視Footer.ascx的內容，您會發現其中只有HTML標示，完全沒有ASP.NET的程式，這樣的 .ascx檔案也能構成Pagelet嗎？答案是肯定的，最簡單的Pagelet就是只含有HTML標示的 .ascx檔案，接著讓我們來看看使用這個這個Pagelet的網頁UseFoot.ASPx：
<%@ Register TagPrefix="kj" TagName="Footer" Src="Footer.ascx" %>
<Html>
<Body BgColor="White">
<H3>使用最簡單的 Pagelet -- UseFoot.ASPx<HR></H3>
<Blockquote>
檢視 Footer.ascx 的內容，您會發現其中只有 HTML 標示，完全沒有
ASP+ 的程式，這樣的 .ascx 檔案也能構成 Pagelet 嗎？答案是肯定
的，最簡單的 Pagelet 就是只含有 HTML 標示的 .ascx 檔案。
</Blockquote>
<kj:Footer id="Footer1" runat="server"/>
</Body>
</Html>
網頁瀏覽的結果如圖-13。

圖-13 UseFoot.ASPx瀏覽的結果
除了只含有HTML標示最簡單的Pagelet之外，Pagelet也可以含有屬性及方法，對於含有屬性及方法的Pagelet來說，其用法與Server控制元件完全相同。當我們覺得 .NET Framework 所提供的Server控制元件不夠用時，可以利用製作Pagelet的功能來建立我們自己的Server控制元件。

Web Services

不像ASP網頁只能存取本機資料庫，ASP.NET則提供了Web Services功能讓我們跨越網際網路存取遠端的資源。在VB6時代，微軟發表了RDS(Remote Data Service)，也可以讓我們存取網際網路上另一部Server的資料庫，但它仍有兩大缺點：(1) 一般使用者上手不易 (2) 無法跨越平台：使用RDS跨越網際網路存取資料庫，不管Server端或Client端，都必須使用Windows作業系統。
Web Services(Web服務)改良了RDS的缺點，除了變得比較容易上手之外，Web Services採用XML為資料傳輸的格式，使得資料得以跨越平台，而更重要的是，ASP.NET網頁也可以享用這種服務，也可以提供這種服務。
在作業模式上，讓筆者舉個實例來說明，請參閱圖-14，假設瀏覽器會存取Server A的網頁，但Server A的資料庫來自ServerX，那麼Server X要提供一存取資料庫之Web Service，另一方面Server A則要建立Web資料庫代理程式，然後透過Web資料庫代理程式與Web Service的資料交換(採用XML格式)，進而達到存取Server X資料庫的目的。

圖-14 存取Web資料庫(跨越網際網路的資料庫)

結語

也許過去兩三年電子商務真的被高估了，但網頁製作技術卻已成為資訊人必備的知識。雖然自從微軟發表IIS以來，ASP一直被低估了，所以只是IIS的附屬品，現在很高興ASP.NET終於從IIS之中獨立出來，而且功能與VB、C#…等程式語言看齊，相信未來的ASP網頁製作將進入另一個嶄新的世紀。