asp.net中容易犯的錯誤

來源:互聯網
上載者:User
asp.net|錯誤

   今天在論壇中閑逛,看到有哥們問ASP。NET編程時要注意哪些問題,有哥們是這樣回答的,寫了洋洋洒洒的21大點。個人認為裡頭這些規則應該按照項目的實際情況來定,要提倡辨證唯物主義嘛。。
    仔細看了看也發覺自己在項目開發過程中的確有這樣的毛病,這些毛病也算是ASP過程中遺留下來的吧,要給自己習慣好好的改改了。

  1. 使用server side include給ASPX引入共同的頁面構圖.
在ASP.NET的機制下, 應使用ASCX(web user control)來實現. ASCX提供了更多可控制介面. 並且更重要的是, ASCX是一個類. 一個實實在在的類. 可以全面控制它.

  2.不使用web.config
  web.config提供了非常豐富的組態管理介面. 是一個應用程式最核心的部分. 但是很多人的web.config往往是空的. 或者就從來沒有修改過.

web.config 主要是保留伺服器的配置的和全域的資訊,這個在Telligent Systems 的 forums的代碼中大大的體現:
1。引入名稱空間資訊
2。資料訪問、檔案上傳目錄,資源檔目錄等全域資訊

  3.使用Response.Write向前端輸出訊息
  ASP.NET平台下的Response和ASP的Response有很大的不同. 雖然表示同一含義, 但用法上已經大不相同. Response.Write的內容只會輸出到頁的最前端. 向前端輸出訊息的正確方法是使用PlaceHolder.
~~~~~~~~~~~
這點說不上是任何技巧,熟悉HTML的人都應該知道這樣做


  4.使用一系列session系統管理使用者串連狀態
  這種方法在ASP裡被濫用. 在ASP.NET環境下, 正確的做法應該是設計一個類. 結構化地儲存資料. 將對session或者cookie的訪問封裝起來.
~~~~~~~~~~~~~~
意思應該是說把使用者這個對象儲存起來吧,這個的確應該如此

  5.使用session驗證身份
  這幾乎是通病. ASP.NET提供了一組用於使用者身分識別驗證的API. 類型是forms驗證或者windows驗證. 這一點quick start有一節講解得很清楚. 可以絕大部分人還是依靠給session賦值來保持使用者身分識別驗證狀態.

~~~~~~~~~~~~~~
很多人的確是這樣使用,自己也有這樣的毛病,應該改改

  6.使用Response.Redirect重新導向頁
  這一點在必要的時候可以使用. 但不可濫用. 事實證明濫用重新導向將導致邏輯上的嚴重混亂. 這是在以頁為程式單元的時候的做法. 使用front controller模式將使使用者的操作邏輯集中起來]

~~~~~~~~~~~~~
response.redirect 只是頁面跳轉而已

  7.使用太多ASPX頁
  ASP環境下的程式單元只有*.asp頁, ASP.NET可不是這樣, 還有後端的類庫, ASCX等等. 應將商務邏輯分別集中在不同的單元, 而不應該一項操作使用一個ASPX. 更多時候ASPX將做為ASCX或者custom control的容器而管理頁內邏輯. ASPX重用ASCX的同時, ASPX也做為統一的頁構圖重用.

  8.在多個邏輯單元之間複製代碼並修改相應邏輯
重用. 重用. 重用. 處理此類問題的原則是不出現任何相同或相似的過程. 如果你用上面的方法, 一旦出現重大邏輯更改, 帶來的結果將是災難性的.
~~~~~~~~~~~~~~~~~~~
增加代碼複用性,就應該少“複製”代碼

  9.害怕使用DataSet.
  很多人被DataSet嚇壞了. 認為”肯定”影響效能. 但連最初的嘗試都不敢. 他們總認為他們的產品一定重大, 設計上應該”謹慎”. 他們往往使用ArrayList或者設計低級的類來儲存集合資料. 進行艱難的資料倒入工作.
~~~~~~~~~~~~~~~~~~~~~~~
自己設定的類也是有自己的好處的,如果資料集合之後沒有聯絡,那直接用dataTable即可。

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

~~~~~~~~~~~~~~~
如果開發使用人數比較少的系統,效能考慮倒不是主要,因為一般的伺服器都可以伺候比較多的人數,如果效能可能成為系統瓶頸,那就應該大大的最佳化,少用伺服器控制項

  11.應用程式根目錄很亂.
  ASP.NET是開發項目. 不是網站. 應該把不同的資源分類放置. 例如把所有靜態資源(樣式表, 指令碼, 映像)組織到一起. 甚至可以寫一組API來管理他們. ASPX應該放在一起. ASCX應該放在一起. .*.cs呢? 應該把他們放到另外一個project裡.
~~~~~~~~~~~~~
 這個同意,至少資料訪問層要做為單獨的類庫。

  12.不厭其煩的寫訪問資料庫的過程
應該把這工作交給DataAccess Application Block. 你自己還要開關connection, 何苦呢.

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

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

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

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

  17. 零ASCX
  不用說, 他還沒學會ASP.NET

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

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

  20.零注釋
  這些都是心裡很明白的快手. 一任IDE產生的預設注釋橫在那裡不管.

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

 



相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.