作者：mechiland (http://www.jzchen.net)

動筆時間：2003年4月21日

完成時間：2003年4月29日

目錄：

概述

歷史
先進的技術與好用的技術：
asp到了盡頭嗎？
組件化的Web程序
      一個實例
      小技巧
      結束語

概述

本文簡要描述了Web開發的歷史，并主要對jsp, ASP, 以及asp.net進行了比較。最后，較為詳細的提出了一種概念模型并做出了簡單的實現。這種模型將使得ASP這種簡單易用的技術上升一個高度，成為中小企業或者中小項目開發的較好選擇。本文適合ASP的中高級開發者。

歷史

如今的Web應用程序越來越流行，基于B/S結構的軟件也日漸增多。這也不難想象，正如Sun公司總裁Scott所說，“計算機就是網絡”，隨著互聯網技術的發展，知識在世界范圍內得到充分的傳播。從90年代很原始靜態HTML頁面（現在還能在舊書攤看到講解HTML3.2的書，配上16位的Internet Explorer或者Netscape Navigator插圖，那時候的網頁美觀水平跟現在已經不能相提并論了），到復雜而缺乏定制性的CGI，然后是WindowNT的興起，出現一種叫IDC，IDA, IDQ的東西（當然，現在那些東西已經不存在了，只是作者當年還興致勃勃的研究過他們，但是現在什么也記不住了），然后就是基于VBScript的ASP2.0。這是后，java逐漸侵入Internet編程領域，Servlet、JSP也出現了。其他的，如php, Perl, 等，到現在微軟大行其道的以ASP.NET為核心的.Net技術，如今的Web開發領域可謂百花齊放，各有千秋。

技術出現了這么多，無論是ASP、JSP還是PHP等，在出現的早期，他們的編程模型不外乎是下面的模式：客戶機向服務器提交一個HTTP/GET或者HTTP/POST請求，服務器得到這個請求后，要么請求數據庫，將結果響應給客戶端，要么直接響應一個結果給客戶端。也就是簡單的“請求-響應”模型。這種模型的唯一的一個優點就是簡單。隨著大型的Web應用的出現，這種模型很快出現不足。例如，無法實現代碼的重用（在Web開發中，出現冗余代碼似乎是難以避免的事），很多頁面具有相似的功能與相似的代碼，在需求改變的時候，代碼的更改顯得如此的不便，以至于讓人很惱火。無法實現復雜的業務邏輯，簡單的結構決定了這種模型無法勝任復雜的邏輯。等等，諸如此類的問題，使得Web開發的前輩們開始考慮更為有效的模式。

這時候值得一提的是JSP Model2, 也就是SmallTalk語言中一種很常見的模式：Model-View-Controller。有關這種模式的有相關的專業文章介紹，這里就不再贅述?？偠灾?，這種模式的出現改變了大多數Web開發人員的觀念，使他們以一種軟件結構的高度上來考慮B/S軟件，而不是原來的“流式開發”。實現了MVC模式的Apache Struts，一時成為開發人員了與學習和接受的一種新的技術。（有關JSP與Servlet，請看我翻譯的另外一篇文章：《Servlet與JSP， 最佳實踐》）

ASP.NET的推出可以說是又是一個進步。Code-Behind技術與頁面回調等，姑且不論其效率如何，單單從這些技術本身而言，又將我們的Web開發觀念提高了一個層次。服務器HTML組件可以直接與C#代碼交互，而且如此的自然，不得不佩服微軟的結構設計了。

現在我們來談一談這篇文章的主題：ASP。

先進的技術與好用的技術

目前在Web開發領域，幾乎沒有人看好ASP。CSDN上總有人在抱怨ASP開發者的薪水太少。而且ASP確實存在這樣和那樣的問題，最大的問題莫過于它是非編譯的腳本，所有的腳本都是通過解釋執行，這讓他的效率大打折扣。另外，它的弱類型變量定義降低學習的難度與他的效率。種種的問題顯示，放棄ASP吧，不要在追尋一個落魄的技術了。

然而，我想沒有一個有經驗的Web開發者會說，ASP不好用，ASP不好學?，F在的ASP高手很多，然而JSP，ASP.NET的高手卻很難培養。在CSDN的JSP版上，問“怎么配置JSP運行環境”一類的問題不在少數，另外一些例如“字符編碼”、“數據庫連接”等在ASP種基本不用考慮問題在JSP中確實屢見不鮮。這里我無意比較ASP與JSP，我也不敢攻擊JSP或者說JSP的壞話。從純粹的技術的角度，我認為，在易用性上，ASP要稍勝一籌，而且在中小型項目的把握上，拋開個人或者技術界的虛榮心，ASP要比JSP把握大。如果讀者是一位有多年經驗并且熟知ASP與JSP的話，應該不至于反對我的觀點。

然而，JSP的優點比比皆是。從軟件結構的高度來看，它太優秀了。擁有JavaBean技術與擴展標記庫技術，使得JSP的概念已經遠遠超過了它本身。組件化容易，高效率，擴展方便，容易實現多層結構，等等。

從現在Web開發領域的走勢（或者說整個軟件的走勢）來說，組件化的思想越來越重要了?，F在的問題是，基本的ASP功能很明顯是無法滿足現在日益復雜的需求，如何在ASP中實現組件思想呢？

關于組件我們能夠想到最直接的辦法就是使用VisualBasic或者VisualC++或者任何一種其他的Windows環境下的編程工具。然后，幾乎所有人都會說：VC開發組件是效率最高的，但是很慢；VB開發式最快的，效率也不錯。的確，VB具備簡單通用，支持COM, COM+，等優點，而且開發速度快，調試方便。這樣，VB就成為開發ASP組件的首選。另外一個不得不提的東西就是xml。使用XML的好處多多，這里也不多說了。

我的基本思想是：用VB來寫組件，用XML來配置應用程序。這里的組件的概念已經不是過去的那種功能性組件（例如，SAFileUpload, jmail等等，只是為了實現某一個功能而實現的組件。目前這類組件占據了大多數的ASP服務器端組件市場。），更多的是實現某一個實體(Entity)。也就是說，在面向對象的ASP技術中，提倡兩種組件的存在：功能組件與實體組件。

功能組件主要用于實現某一個或者一組功能。當然，這些功能也應當是按照面向對象的思想組織在一起。例如，一個名為LoginControl的功能組件包含以下方法：CheckLogin, UpdateLogin, LoginOut等，更為常見的例子就是數據庫操作。您可以將數據庫操作寫成組件的方法，在ASP頁面中進行調用。而實體組件僅僅實現基本的對象及其屬性和方法。最普通的應用的例子莫過于User 組件，它可能有Name, Account, PassWord等等屬性。使用用戶組件最顯著的好處是：充分利用廉價資源――內存來存儲邏輯上獨立的一個復雜對象，從而減少昂貴資源（例如數據庫鏈接）的使用。

而XML的作用是提供應用的簡單配置，在ASP頁面與組件之間建立一種松散聯系。有了這種聯系，應用程序就可以以一種非常隨意而輕松的方式進行分工、拆卸和組裝。這種想法來自于現在的MVC Struts中的struts-config.xml和ASP.NET中的web.config。

關于VB組件的注冊一直是一個大問題。現在的Web應用已經遠遠超過了過去的概念。原來只是做做網站，現在卻可以做復雜的應用系統，而且不僅禁止運行在ISP的虛擬主機上，越來越多的應用被部署到企業的內部網絡。既然如此，VB中組件的注冊已經不成為問題，一般來說，除非必要，否則在一個項目中使用一個dll足夠了。當然，在開發過程中的調試也許是非?？菰锏?。在本文的最后，有一些組件調試的小技巧，如果你真的打算用這種方式來開發Web應用的話，你可以參考一下。

下面是一個實際的例子。由于時間、環境的原因，作者僅僅在自己的機器上對代碼進行了運行和測試，由于篇幅所限，作者也不提供整個樣例的代碼（如果讀者熟知ASP與VB的話，實際上代碼是非常簡單的），下面的例子僅僅是一個簡單的開發原型。在實際的系統使用中需要考慮更多的因素。

一個會員注冊、登錄、注銷的例子：

下面這個例子采用上面提到的面向對象的思想。在這個小型示例中，包括了以下幾個部分：

User類 用來模擬在應用系統中的一個實體

DataPRovider類 提供所有的數據庫操作

Globals類 讀取配置xml文件

（以上類被封裝到ExtendPortal.dll中。）

一些相關的asp文件

假定我們的站點名稱為ExtendPortal

1、  定義xml文件(app-config.xml)

<?xml version="1.0" encoding="gb2312"?>

<app-config>

<!--Define the site infomation-->

<site-info>

    <name>ExtendPortal</name>

</site-info>

<!--Define data source informations-->

<data-sources >

       <data-source>

       <name>accessDB</name>

       <value>DSN=ep</value>

</data-source>

</data-sources >

<!--Define the resources-->

<resources>

    <resource key="urlHome" value="/index.asp" />

</resources>

</app-config>

上面只是一個例子，你可在實際的項目中根據需求進行定義。

類圖如下所示：

（圖1）

系統的處理流程如下：

根據上圖所示，一個完成的Web開發的項目就可以以一種結構化程度很高的方式進行組織和搭建，而且在整個系統的模型中，處處體現著面向對象的思想，用這種模型實現的多層結構模塊之間聯結松散，分工、組織都非常容易。當然，這種模型的最大的“缺點”就是在初期的時候需要花較多的時間分析用戶的需求，并且由此分析出相應的實體組件和功能組件。然而，這似乎是所有正常運轉的項目的通用特點。

開發技巧

到此，讀者應該對作者提出的這種模型有了一定的了解。但是，在實際的開發中還需要注意很多問題，這其中最大的問題莫過于組件的調試。每次重新編譯組件都要重新注冊，甚至有可能要IIS重啟。下面的一些小技巧也許能夠幫你減少這些煩惱：

1 小心的編程！不要讓編譯器幫你找到那些簡單的錯誤，例如變量未定義，函數用錯等等。這些錯誤往往占據了調試的大多數時間。

2 選擇一種合適的線程模型。千萬不要用單線程編譯你的組件，原因自己想吧。

3 通過將Web程序的進程環境設置“高”，然后你可以通過卸載應用程序的方式來重新注冊組件，而不用重新啟動IIS.

結束語：

本文論述了一種新的ASP編程模型，它與一般的COM組件并不一樣，而在其中提出了實體組件的概念。希望這篇文章能夠幫助那些為了降低開發風險而使用ASP的中小型項目或者開發人員提供一個更高層次的幫助。