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

2002年前的转贴 专栏收录该内容
6 篇文章 0 订阅
.NET Framework環境下的ASP網頁製作

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

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

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

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

從ASP到ASP.NET

ASP會變得很紅,恐怕連微軟也覺得意外,因為ASP一直都附屬於IIS,算不上獨立的產品。IIS版本與ASP版本的對應如下:

IIS 版本附帶在 IIS 底下的 ASP 版本
IIS 3.0ASP 1.0
IIS 4.0ASP 2.0
IIS 5.0ASP 3.0

有人會用1.02.03.0來區分ASP的版本,但筆者不以為然,因為從ASP 1.0版到3.0版,微軟並沒有花太多心思來改良ASP,只是因為IIS改版了,所以ASP也跟著做微幅的改版,因此從ASP 1.0版到3.0版,在功能上並沒有顯著的改變,所以不管ASP 1.02.03.0,筆者都叫它們ASP

隨著ASP的使用者越來越多,希望ASP更好的聲音也越來越強烈,也許是從善如流,也許是為了推廣 .NET Framework,微軟針對ASP的使用者做了市場調查,找出ASP必須改良的地方,而發展了下一代的ASP,也就是ASP.NET(或者稱為ASP+)

ASP.NET與ASP的相容性

ASP升級到ASP.NET,大家最擔心的問題可能是「會不會影響既有ASP網頁的運作」,筆者將ASP作業平台升級到ASP.NET作業平台之後(本文撰寫時所安裝的ASP.NET版本是Beta 1),還沒有發現既有的ASP網頁不能運作或必須修改的。

在實際運作上,當ASP網頁( .asp為副檔名)被瀏覽時,IIS會啟動asp.dll來執行ASP網頁,而當ASP.NET網頁( .aspx為副檔名)被瀏覽時,IIS則會啟動xspwp.exe來執行ASP.NET網頁,兩者的執行檔案不同,因此不只是安裝ASP.NET之後,不會影響既有ASP網頁的運作,實際上ASP網頁及ASP.NET網頁是並存的。

另一個常問的問題是:需要將現有的ASP網頁轉換成ASP.NET網頁嗎?由於ASP網頁及ASP.NET網頁是並存的,因此運作得很順利的ASP網頁可以暫時不必修改,至於哪些網頁必須採用ASP.NET?以下是筆者的建議:

  1. 希望效能更高時:當ASP.NET網頁第一次被瀏覽時,Server會先將其編譯成MSIL(Microsoft Intermediate Language),並且儲存下來,而再度被瀏覽時,即不再重新編譯(除非 .aspx檔案的內容有所改變),因此可以提升不少效能。此外,ASP.NET還具備網頁及資料Cache功能(見稍後介紹),亦可提昇網頁的回應速度。
  2. 需要經常維護或修改的網頁:由於ASP.NET採用VB7為程式語言,具備完整的物件導向功能,有助於網頁的維護。
  3. 未來新開發的網頁:既然ASP.NET功能優於ASP,未來開發的網頁當然要採用ASP.NET

程式語言的改變

ASPASP.NET,其中的改變相當多,不過與ASP網頁製作者最有切身關係的應該是程式語言的改變,ASP只接受VB ScriptJava Script兩種程式語言,但是對ASP.NET來說,舉凡可以編譯成MSIL的程式語言,都是ASP.NET可以接受的程式語言。

筆者在Run!PC3期的「.NET Framework -- 微軟新一代的軟體開發環境」一文中介紹過MSIL,它是一種中介語言,介於高階程式語言(例如VB)及機器碼之間的語言,在ASP.NET底下,我們撰寫的程式語言也會先編譯成MSIL,然後MSIL再被編譯成機器碼加以執行,過程如圖-1ASP.NET也是採用此一模式,除了會輸出資料到瀏覽器之外,ASP.NET網頁與其他的程式語言的工作模式都是相同的。


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

執行效能的質疑

第一次接觸ASP.NET網頁的人可能會有這樣的疑問:「執行效能好像不如ASP網頁?」,關於這個問題,讓筆者從運作模式來談起,首先請看圖-2,可看出ASP.NET網頁比ASP網頁要多一次的編譯工作。


圖-2 ASP與ASP.NET運作模式的比較

儘管ASP.NETASP網頁多一次的編譯工作,但這並不表示ASP.NET的執行效能一定比較差,參考圖-2ASP.NET階段二的編譯執行速度優於ASP,但ASP.NET階段一的編譯速度卻慢於ASP,簡單地說,ASP.NET階段一及階段二合起來的時間 ASP執行的時間。

如果從以上的比較來看,ASP.NET確實比ASP慢,但是請再把網頁的瀏覽分成以下兩種情況:(1) 網頁第一次被瀏覽 (2) 網頁第二次被瀏覽,如圖-3ASP.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 DLLActiveX EXEActiveX Component等多種ActiveX物件,不過這個現象在 .NET Framework底下已經有所改善,在 .NET Framework所提供的物件類別中,除了少數與螢幕輸出有關的物件類別(例如WinFormConsole)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端的狀態,必須使用SessionCookie物件,但不管是SessionCookie物件,都必須在上網者開啟瀏覽器的Cookie功能之下方可運作,ASP.NET改善了此一現象,只要我們將Server控制元件佈置在WebForm之中,WebForm就會記錄所有Server控制元件的狀態(例如控制元件中所輸入的文字)

記錄控制元件狀態的能力,以須分成多次輸入的表單最為方便,以圖-4的輸入表單為例,若使用ASP的設計,在步驟一及步驟二所輸入的資料必須記錄在SessionCookie物件中,供步驟三讀取,但是對ASP.NET網頁,只要將步驟一、步驟二、步驟三的Server控制元件佈置在同一個WebForm之中,則不管網頁執行到哪一個步驟,都可以讀取上網者在Server控制元件中所輸入的資料。


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

ADO+與資料控制元件

.NET Framework所提供的資料庫存取物件稱為ADO+(Active Data Object+),雖然有不少觀念與ADO相類似,但卻是全新的物件,為什麼已經有ADO了,還要再提供ADO+呢?筆者覺得原因可能有幾:

  • 採用XML做為資料交換格式:由於XML已經成為網際網路交換資料的標準,這是個不得不的舉動。
  • 延伸資料的範圍:在ADO底下,任何資料都必須透過OLD DBODBC來存取,ADO+ 並無此一限制,任何程式都可以藉助ADO+ 所提供的物件讓自己成為新資料格式的提供者,這因此延伸了可存取之資料的範圍。
  • 與資料控制元件的整合:以往我們撰寫ASP網頁時,最不方便的地方是資料庫內容的顯示,為了顯示資料庫的內容,大概必須藉助ADORecordset物件逐筆讀取資料錄,然後再逐筆將其顯示出來,程式較冗長,在ASP.NET網頁中,我們只要佈置好DataGridDataListRepeater這一類資料控制元件,然後與ADO+ 進行繫結,DataGrid等控制元件就會自動顯示資料庫的內容。參閱圖-5及圖-6就是分別使用DataGridDataList控制元件顯示資料庫內容的網頁。

圖-5 http://www.kjedu.com.tw/kjaspx/ch01/AspxPage.aspx 網頁

圖-6 http://www.kjedu.com.tw/kjaspx/ch01/DataList.aspx

Cache與效能的提升

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

Trace.Write("UploadFile()", "進入UploadFile事件程序")
Trace.Warn ("UploadFile()", "進入For迴圈")

結果可將訊息輸出到Trace Information區段,供我們做為偵測程式的參考。

偵錯工具程式(Debugger)

ASP.NET提供的Debugger程式很像VB的操作介面,可以讓我們設定中斷點、逐步執行程式、觀察變數及堆疊的情況…等,是偵錯的利器。使用Debugger之前,須在config.web檔案中增加以下的設定:

<compilation debugmode="true"/>

接下來啟動C:/Program Files/Microsoft.Net/FrameworkSDK/GuiDebug目錄的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.NETVB7為程式語言,所以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之中獨立出來,而且功能與VBC#…等程式語言看齊,相信未來的ASP網頁製作將進入另一個嶄新的世紀。


  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值