有很大一部分ASP.NET程序員是由ASP遷移過來的. 這本是一個很自然的過渡. 殊不知ASP.NET與ASP相比是一個全新的技術(shù). 他們僅僅是名字上相似. 或者為了技術(shù)的延續(xù)性而特意保留了一些類似的API而已. 但是這帶來了問題. 很多人僅僅以為ASP.NET是ASP的升級, 或者是.NET版本. 哪里知道.NET是一項全新的應(yīng)用平臺. 如果把ASP看作貝殼, 那么ASP.NET將是海洋.

但是太多的人沒有意識到這一點(diǎn). 或者看不全. 很多人按照他們習(xí)慣了的方式繼續(xù)寫ASP.NET應(yīng)用. 縱然積習(xí)的力量是巨大的, 但改變就必須有陣痛, 不徹底根除一些不合適的做法, 就難以獲得真知。

以下列舉的都是錯誤的做法, 請不要誤以為是推薦的做法而進(jìn)行推廣:

1. 使用server side include給ASPX引入共同的頁面構(gòu)圖.
在ASP.NET的機(jī)制下, 應(yīng)使用ASCX(web user control)來實(shí)現(xiàn)統(tǒng)一的頁面構(gòu)圖. ASCX提供了更多可控制接口. 并且更重要的是, ASCX是一個類. 一個實(shí)實(shí)在在的類. 可以全面控制它. 給ASPX使用server side include 將會帶來很多問題。

2.不使用web.config
web.config提供了非常豐富的配置管理接口. 是一個應(yīng)用程序最核心的部分.  但是很多人的web.config往往是空的. 或者就從來沒有修改過.

3.使用Response.Write向前端輸出消息
ASP.NET平臺下的Response和ASP的Response有很大的不同. 雖然表示同一含義, 但用法上已經(jīng)大不相同. Response.Write的內(nèi)容只會輸出到頁的最前端. 向前端輸出消息的正確方法是使用PlaceHolder.

4.使用一系列 session 管理用戶連接狀態(tài)
這種方法在ASP里被濫用. 引入過多的 session 將會使應(yīng)用變得極難管理. 在ASP.NET環(huán)境下, 正確的做法應(yīng)該是設(shè)計一個類. 結(jié)構(gòu)化地保存數(shù)據(jù). 將對session或者cookie的訪問封裝起來.

5.使用session驗證身份
這幾乎是通病. ASP.NET提供了一組用于用戶身份驗證的API. 類型是forms驗證或者windows驗證. 這一點(diǎn)quick start有一節(jié)講解得很清楚. 可以絕大部分人還是依靠給 session 賦值來保持用戶身份驗證狀態(tài).

6.使用Response.Redirect重定向頁
這一點(diǎn)在必要的時候可以使用. 但不可濫用. 事實(shí)證明濫用重定向?qū)��?dǎo)致邏輯上的嚴(yán)重混亂. 這是在以頁為程序單元的時候的做法. 使用front controller模式將使用戶的操作邏輯集中起來]

7.使用太多ASPX頁
ASP環(huán)境下的程序單元只有*.asp頁, ASP.NET可不是這樣, 還有后端的類庫, ASCX等等. 應(yīng)將業(yè)務(wù)邏輯分別集中在不同的單元, 而不應(yīng)該一項操作使用一個ASPX. 更多時候ASPX將做為ASCX或者custom control的容器而管理頁內(nèi)邏輯. ASPX重用ASCX的同時, ASPX也做為統(tǒng)一的頁構(gòu)圖重用.

8.在多個邏輯單元之間復(fù)制代碼并修改相應(yīng)邏輯
重用. 重用. 重用. 處理此類問題的原則是不出現(xiàn)任何相同或相似的過程. 如果你用上面的方法, 一旦出現(xiàn)重大邏輯更改, 帶來的結(jié)果將是災(zāi)難性的.

9.害怕使用DataSet.
很多人被DataSet嚇壞了. 認(rèn)為”肯定”影響性能. 但連最初的嘗試都不敢. 他們總認(rèn)為他們的產(chǎn)品一定重大, 設(shè)計上應(yīng)該”慎重”. 他們往往使用ArrayList或者設(shè)計低級的類來保存集合數(shù)據(jù). 進(jìn)行艱難的數(shù)據(jù)倒入工作.

10.對“性能”過多注意.
對ASP.NET ViewState的機(jī)制特別不滿. 或者總是挖空心思迫害人家. 反倒把自己弄得很累. 如果在對付ViewState的同時多注意少連幾次數(shù)據(jù)庫也許更文明些.

11.應(yīng)用程序根目錄很亂.
ASP.NET是開發(fā)項目. 不是網(wǎng)站. 應(yīng)該把不同的資源分類放置. 例如把所有靜態(tài)資源(樣式表, 腳本, 圖像)組織到一起. 甚至可以寫一組API來管理他們. ASPX應(yīng)該放在一起. ASCX應(yīng)該放在一起. .*.cs呢? 應(yīng)該把他們放到另外一個project里.

12.不厭其煩的寫訪問數(shù)據(jù)庫的過程
應(yīng)該把這工作交給DataAccess Application Block. 你自己還要開關(guān)connection, 何苦呢.

13.自己寫的東西最靠得住.
事實(shí)往往正好相反. 多注意使用人家寫好的產(chǎn)品. 又不收你錢, 何苦那么愛面子呢.

14. 胡亂命名ASPX文件名
這是最讓人痛苦的了. ASPX文件名不僅需要容易識別. 還應(yīng)該遵循一定規(guī)則. 因為behind每個ASPX都會有一個同名的類, 想象一下, 多難受. 另外大部分人不知道管理自己的項目的name space. 讓人好像看到一本帳一樣.

15.從來不作繼承或派生
一些具有相同行為的類, 應(yīng)該從公共的基類派生出來. 實(shí)際意義上, 我們的ASPX應(yīng)該有一個基類PageBase. 因為總有一些公共的特性需要抽象出來.

16.零property
他們的類(ASPX所對應(yīng))里只有private method. 不公開自己的任何秘密. 可以這一定是JAVA的遺老干的事.

17. 零ASCX
不用說, 他還沒學(xué)會ASP.NET

18.使用DreamWeaver“畫“ASPX
這批人是美工. 甚至有一些人在非常陶醉地討論如何更好地“整合“ DreamWeaver和Visual Studio.

19.只熟悉System.Web.UI.WebControl和System.Data.SqlClient
應(yīng)該還有一些值得熟悉的類庫.

20.零注釋
這些都是心里很明白的快手. 一任IDE生成的缺省注釋橫在那里不管.

21.零事件
對“事件驅(qū)動“一無所知. 只知道在Page_Load()里寫過程. 或者雙擊一個按鈕寫Xxx_Clock()過程. 在他們的程序里看不到event和delegate.

22. 研究在“頁間傳值“
典型的做法是討論總結(jié)出幾種頁間“傳值的方法“. 例如使用query string, 使用session, 使用form post 等等. 豈不知ASP.NET下的form是缺省的post到本頁的. 我們也許再也不需要使用Request.Form[“name“]獲得表單的值了. 雖然框架保留了這樣的接口.
實(shí)際上, 在ASP.NET環(huán)境下, 很少在模塊或者程序單元間傳送常規(guī)類型的值. 在事件驅(qū)動的機(jī)制下, 我們一般不會讓某頁去主動獲取想象中的“傳值“, 這些過程一般被封裝在事件或者狀態(tài)中. 所以也就不存在頁間或者窗口或者框架間傳值的問題. 一般而言, 我們會有專用的深層機(jī)制隱藏這一過程. 掌握這樣一個原則: 在業(yè)務(wù)過程中避免接觸過多系統(tǒng)的接口.

以上是想到哪寫到哪, 大家如果碰上讓你深惡痛絕的事, 也可以補(bǔ)充.
僅僅是個人看法.