ASP.NET移植須知（續）
2024-07-10 12:58:31
供稿：網友
'asp syntax (implicit retrieval of column value property)
set conn = server.createobject("adodb.connection")
conn.open("testdb")
set rs = conn.execute("select * from products")
response.write rs("name")
'asp.net syntax (explicit retrieval of column value property)
conn = server.createobject("adodb.connection")
conn.open("testdb")
rs = conn.execute("select * from products")
response.write (rs("name").value)
數據類型的變化
在visual basic .net，整數值現在是32 位。long數據類型為64 位。
當從asp.net中調用com對象的方法或是在您自定義visual basic components組件中調用microsoft® win32® api，都可能發生問題。您特別要注意實際需要的數據類型，以確保您正確傳遞數值。
結構化的例外處理
雖然在visual basic .net中，仍然沿用熟悉的on error resume next 及on error goto 錯誤處理方法，但是，它們不再是最好的方法。visual basic現在有成熟的,系統的例外處理方法。它們使用try, catch, 及 finally等關鍵字。如果有可能的話，您應該轉向這種新的錯誤處理模式，因為它運用了一個性能更加完善，穩定的機制來處理應用程序錯誤。
與前面介紹的.net 框架與asp.net相比,com基本沒有變化。但是，這并不是說您從asp.net上運用它們時，您完全不需要顧及com對象及它們的行為。以下是幾點您必須注意的要素：
線程模式變化
asp.net線程模式是multiple threaded apartment (mta). 這就是說，您所用的為single threaded apartment (sta)而生成的組件，在asp.net中，如不采取特別預防措施，不再會可靠工作。這包括，但不局限于，用visual basic 6.0及先前版本生成的所有com組件。
aspcompat 屬性
現有的sta組件不需要任何修改就能使用。 您所要做的僅僅是在asp.net頁面的<%@page>標簽中加入指示兼容的屬性aspcompat=true。比如，<%@page aspcompat=true language=vb%>。使用這個屬性會強制該頁面在sta模式下執行，從而確保您的組件正常工作。如果您的頁面不指定本屬性而直接引用sta組件，在運行時將發生異常。
設置aspcompat=true也將使您的頁面能夠調用那些需要使用asp內建對象的com+1.0組件。這可以通過objectconect對象來實現。
設置本屬性會導致一定的性能下降。我建議您僅在必要的情況下使用它。
預先綁定與滯后綁定
在asp中，所有對com組件的調用都是通過idispatch接口進行的。由于所有調用都需要在運行時由idispatch間接處理，我們稱之為滯后綁定。在asp.net中，如果您愿意，您仍然可以使用這種方式來完成對象調用。
dim obj as object
obj = server.createobject("progid")
obj.mymethodcall
以上代碼能夠工作，但這并不是我們所推薦的用法。在asp.net中，您可以利用預先綁定直接創建您需要的對象：
dim obj as new myobject
myobject.mymethodcall()
預先綁定能使您的頁面在與組件的交互過程中避免出現類型錯誤。為了使用預先綁定，您需要在項目中加入一個引用，正如您在vb6.0項目中加入一個com組件引用一樣。假設您使用的開發工具是visual studio.net，vs.net將會在后臺創建一個位于com組件之上的代理對象，讓您感到就像在使用.net組件一樣方便。
至此您可能會提出性能問題。為了保證與com的互操作性，我們引入了代理對象，這的確會帶來一定的性能負擔。然而，在大多數情況下，您并不需要擔心由此而引發的性能下降。畢竟，與冗長的idispatch調用相比，代理對象所執行的cpu指令幾乎可以忽略不計。您所贏得的遠遠超過您所失去的性能。當然，理想的狀況是完全使用新創建的，被管理的(managed)對象。然而，理想狀況近期還不可能達到——我們必須保護在過去幾年里對com技術的投資。
onstartpage和onendpage方法
在使用傳統的onstartpage和onendpage方法問題上，您可能需要多花一些時間。如果您依賴于這兩個方法來訪問asp固有對象，那么您需要使用aspcompat指令，然后用server.createobject以預先綁定的方式來創建對象。見下例：
dim obj as myobj
obj = server.createobject(myobj)
obj.mymethodcall()
請注意我們沒有用“progid”，而是用了預先綁定的實際對象類型。為了保證以上代碼正常工作，您需要在visual studio項目中加入對該com組件的引用，以便vs創建一個預先綁定的包裝類。這里是您必須繼續使用server.createobject的唯一理由。
com小結
表2列出了您為了繼續有效使用現有的com組件所必須做的事情。
表2. 傳統com對象的asp.net設置
com 組件類型/方法
asp .net 設置/例程
custom sta (visual basic 組件 或其它被標志為"apartment"的組件)
使用 aspcompat屬性, 和預先綁定
custom mta (或其它被標志為"both" or "free" 的atl 或自定義的 com組件)
使用預先綁定,不當但不要用 aspcompat屬性
內置對象 (通過objectcontext 對象來訪問)
使用 aspcompat屬性, 和預先綁定
onstartpage, onendpage
使用 aspcompat屬性, 和server.createobject(type)
無論您的組件是否使用com+來部署，以上設置都適用。
在asp中，web應用程序的配置信息都存放在系統注冊表或iis的配置數據庫(metabase)中。在很多情況下，由于服務器缺乏適當的管理工具，察看或修改這些設置成為非常困難的一項工作。asp.net引入了全新的，基于簡單、可讀的xml文件的配置模式。asp.net應用程序在自己的目錄下有一個web.config文件。您可以通過修改web.config文件來控制應用程序的自定義配置，行為，和改變它的安全屬性。
由于習慣的作用，您可能像我一樣還是忍不住要打開internet service manager來查看或修改asp.net應用程序的配置。然而，您必須理解，我們現在有兩套獨立的配置模式。除了一些安全設置，絕大多數由iis管理工具所生成的設置都會被asp.net應用程序忽略。您需要把這些設置放在web.config文件里。
關于.net應用程序的設置有專門的文章討論，我這里不再贅述。表3列出了一些比較有趣的配置。請記住還有非常多的配置項目沒有列在這張表中。
表3. web.config 文件設置范例
項目
描述
<appsettings>
定制應用程序配置
<authentication>
設定asp.net應用程序對身份驗證的支持
<pages>
設定頁面相關的配置
<processmodel>
設置asp.net在iis系統中的進程模式
<sessionstate>
指定一些會話狀態選項
.net基本類庫中有一些類可以用來在程序中簡化應用程序配置訪問方式。
如果您的應用程序使用了session或application固有對象來存儲狀態信息，那么它仍然能夠在asp.net中正確運行。在asp.net中，您有了更多的選擇來存儲狀態相關的數據。
可用的狀態管理方法
asp.net提供了更多的狀態存儲摸式。這使您的應用程序能夠跨越多個web服務器支持web farm范圍內的狀態管理。
您可以用web.config文件中的<sessionstate>部分來配置狀態管理選項。見下例:
<sessionstate
mode="inproc"
stateconnectionstring="tcpip=127.0.0.1:42424"
sqlconnectionstring="data source=127.0.0.1;user id=sa;password=" cookieless="false"
timeout="20"
/>
mode屬性指定了您想要存儲狀態信息的位置。您可以選擇的狀態包括inproc, stateserver, sqlserver, 及off。
表 4. 會話狀態存儲信息
選項
描述
inproc
會話狀態存儲于服務器本地。(asp 風格)。
stateserver
會話狀態存儲于遠程或本地的狀態服務進程。
sqlserver
會話狀態存儲于sql 服務器數據庫。
off
會話狀態被關閉。
當你選用stateserver狀態，stateconnectionstring 會起作用；而當您使用sqlserver狀態， sqlconnectionstring會起作用。對于每個應用程序，您僅可以使用一個存儲選項。
存儲com組件
需要記住的一點是如果您依賴在您的session 或application對象中的傳統com組件的存儲引用，您就不可以在應用程序中使用新的狀態存儲機制(stateserver 或sqlserver)。您只能使用inproc。這是因為在.net中, 那些對象需要能夠自我序列化, 但顯然com 組件做不到. 相反, 您新創建的管理(managed)組件可以相對容易實現這一點，當然也就可以使用新狀態存儲模式。
性能
提到性能，當然沒有免費可言。可以保證的是，在大多數的情況下，inproc會繼續保持其性能之最。緊隨其后的是stateserver和sqlservr。您應當用您的應用程序進行專門測試，以作出最符合您性能要求的選擇。
在asp和asp.net中共享狀態
另一個應當注意的問題是雖然您的工具能夠容納asp和asp.net網頁，但是您不能共享固有會話或應用對象的狀態變量。您可以將信息在兩個系統中進行復制，也可以在您的應用程序完全移植前，提供一個自定義的解決方法。底線是：如果您對session和application對象運用很少，您不會受到很大影響。但就另一方面而言，如果您對這些對象運用很多，您則需要謹慎的運用。您或許可以考慮采自定義一個短期解決方法以共享狀態。
安全性是又一個值得關注的地方。這里提供的是對asp.net安全系統的簡要概括。要獲得更詳盡的信息，請參閱asp.net安全系統的有關文件。
asp .net的安全性主要由web.config文件中的安全設置部分來控制。asp .net與iis協調一致，緊密配合，為您的應用程序提供一個完整的安全模式。一些極少數的iis 安全性設置會以在asp中同樣的方式被asp.net繼承和運用。當然，它還有許多附加的增強組件。
身份驗證
對于身份驗證，asp.net支持列表5中的不同選項。
列表5. asp .net 身份驗證的選項
類型
描述
windows
asp .net用windows 身份驗證.
forms
基于cookie,自定義登錄表.
passport
微軟對外提供passport 服務.
none
沒有進行身份驗證
除了新的passport 身份驗證選項以外，這些選項在asp中是相同的。以windows為基礎的身份驗證在以下例子中的配置下能得到運用。
<configuration>
<system.web>
<authentication mode="windows"/>
</system.web>
</configuration>
授權
當您的用戶通過身份驗證之后，您可以對希望他們訪問的資源進行授權。以下例子說明訪問權限被授予“jkieley”和“jstegman”，任何其他人都將被拒絕訪問。
<authorization>
<allow users="northamerica/jkieley, redmond/jstegman"/>
<deny users="*"/>
</authorization>
扮演
扮演是指一個對象以另一個實體身份標識來執行代碼的過程. 在 asp中, 扮演將允許您的代碼由授權用戶運行.同樣的，您的用戶能夠在一個特殊的標識下匿名運行。在默認情況下，asp.net對模擬并不是有求必應。這與asp是不同的。如果您依賴這個功能，您需要在您的web.config文件中，如下所示，激活該功能。
<identity>
<impersonation enable = "true"/>
</identity>
在移植時另一個要注意的關鍵是數據訪問。通過ado.net的介紹，您現在有了一個高效的新方法來獲取數據。因為數據訪問就它本身而言是個很大的話題，所以它已超出了本文的范圍。對大多數情況而言，您能像以前一樣繼續使用ado，但是我仍推薦您看一下ado.net。這是在您asp.net應用程序中改進數據訪問方法的一種有效途徑。
使用asp .net的準備工作
現在您已知道了大多數您可能碰到的問題，您也許想知道在最終轉向asp.net之前的今天您該做些什么以做好準備。為了讓過程更順利，有很多工作可以做。即使您將來不轉向asp.net，這里的許多建議對您的asp代碼也是有幫助的。
使用option explicit
這是個很好的建議，但并不是每個人都使用它. 當在asp中使用option explicit來強制變量聲明時, 您會至少清楚地了解所有內容在哪里定義，及變量如何定義。一旦轉到asp.net, 我建議您使用option strict. option explicit 在visual basic.net中是默認的。 但是，如果使用更具強制性的option strict, 您就能確保所有的變量都被聲明為正確的數據類型. 雖然這勢必增添額外工作量，但是長遠看來，您將會發現這是很值得的。
避免使用默認屬性
正如我們所討論的，默認的屬性將不再被允許。訪問屬性原本就不是很困難的事。這會使您的代碼更具可讀性，同時，將來移植時也會更節省時間.
使用括號 和call關鍵字
就如本文前面所描述的一樣，應盡可能的使用括號和call 語句。 在 asp .net 中您將會被迫使用括號。現在就使用call語句助您早日養成優良編程習慣，以更好的適應將來的需求。
避免嵌套式包含文件
這點說來容易，做起來難。但是，您應該盡可能地避免嵌套您的包含文件。說得更清楚一點就是， 您應當最大幅度避免重復嵌套文件。久而久之，往往發生的情況是，您的代碼不得不依賴于一個全局變量，而該變量又是在其他地方的包含文件中被定義。您能夠訪問它是因為您的某個包含文件包含了這個您正真需要的包含文件。
當您轉向asp .net,您將很有可能將您的全局變量和程序移入類庫中。這時如果您了解在哪里訪問所有內容，就會方便很多。最后您也許不得不重新放置些文件，并改變一些重名例程的名字。
將功能函數組織成單個文件
在移植過程中的一個策略就是把功能函數和代碼轉移到visual basic 或c#類庫中。相對于多重解釋型的asp文件，您最終可以把所有的代碼放進它所屬的對象。提前組織您的代碼會節省您未來的時間。在最理想的狀態下，您應該可以將子程序編組為邏輯文件。這樣您就能夠非常容易地創建一組vb或者c#類。這些功能在com 對象中恐怕早就該有了。
如果在服務器端的包含文件中您有很多混合的全局變量或常數，不妨將他們也放到一個文件中。一旦您轉向asp.net,您將能很容易的創建一個能容納您所有全局變量或常數的類。這樣您會有一個更有條理，更容易維護的系統。
盡可能地從內容中移掉代碼
您應盡可能的將您的代碼從html的內容中分離開來，這是另一個易說難做的工作。把混有代碼和腳本的函數體清除出函數。這樣做的話，您就會跟好的實現代碼隱藏，因為這是一個asp.net下的理想模式。
請勿在<%%>塊中聲明函數
在asp.net中，這種寫法已經不支持了。您應該把您的函數聲明在<script>塊內。請參考前面結構變化部分中的例子。
避免輸出(render) 函數
與先前討論的一樣，您應該避免使用輸出函數。如果現在您能改變或準備您的代碼，當組建這些類型的函數時，您應該使用”response.write”語句塊。
明確地釋放資源 （調用close方法）
請盡量明確地調用任何close()或您所用對象與資源的釋放方法。就釋放而言，我們都知道visual basic 與vbscript會自動釋放資源。它們一般都能立刻釋放資源，但是，當我們轉向.net，我們沒法確切地知道資源何時被釋放。所以您應該盡可能顯示地釋放資源。
避免混合語言
如果有可能的話，您應該避免在同一頁上混合服務器端的vbscript 與jscript。總的來說，混合不同語言的做法本來就是很糟糕的編程習慣。由于新的編譯模式的變化，每頁要求在<%%>塊內只能有一種語言。這也是一個向asp.net 移植時要注意的問題。您可以繼續使用你習慣的方式編寫客戶端腳本。
總結
綜上所述，在您把您的應用程序遷至asp.net時，您需要注意相當多的方面。我在本文中提出的大多變化應該都是很容易實施的。
如果您的網站很大，當您完成這一過程時，您發現并修復的死代碼，低效程序，bug的數量，可能會多得足以讓您驚嘆。同時，您將能充分享受asp.net 乃至整個.net平臺所帶來的眾多強大功能。
注冊會員，創建你的web開發資料庫，
