小朱® 的技術隨手寫

今天在瀏覽點部落新文章時，看到了這一篇文章，對裡面的內容有一點意見，可能是這篇文章是寫自 ASP.NET 1.x 時代的，所以有些概念和新的作法不太一樣，所以我特別把我的看法說出來。當然也不是在挑戰原著者，而是增補一點自己的看法而已。

1. 使用server side include給ASPX引入共同的頁面構圖.

原文：
在ASP.NET的機制下, 應使用ASCX(web user control)來實現. ASCX提供了更多可控制介面.
並且更重要的是, ASCX是一個類. 一個實實在在的類. 可以全面控制它.

我的看法：
這點我非常同意，應該要依照程式的使用範圍和功能不同而有所區分，但也不是什麼都寫到 ASCX 中，而是要區分為程式碼本體和產生使用者介面的部份，也就是要分成純邏輯控制和控制使用者介面 (Controller/View 切割) 的作法，而不是什麼都放在 ASCX，ASCX 應該是定位在共同使用的 View，而不是功能。

2.不使用web.config

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

我的看法：

這點我也十分同意，如果沒學會操作 Web.config，那等於只學會了一半的 ASP.NET，尤其 Web.config 在應用程式的部署和組態上非常重要，沒有它，你在寫 ASP.NET 應用程式時會十分彆手，等到基礎的設定學好了，可以再進一步學習如何活用 Configuration 來做自己的組態系統，可參考：

http://www.dotblogs.com.tw/regionbbs/archive/2009/05/08/custom_configuration_section_in_web_config.aspx
http://www.dotblogs.com.tw/regionbbs/archive/2009/09/17/orgainzeyoursectionintogroupforconfiguration.aspx
http://www.dotblogs.com.tw/regionbbs/archive/2009/10/09/customconfigurationelementcollection.aspx

3.使用Response.Write向前端輸出消息

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

我的看法：

這要看是在哪裡，一般的使用者介面操作確實不應該使用 Response.Write，因為它會在頁面輸出之前執行，若是使用 Response.Write，則它會破壞原有網頁的 CSS 或樣式，應改用 Label, Literal 或是 PlaceHolder 控制項，並且依控制項插入的作法來處理。但有兩種例外：

1. 輸出的來源是 IHttpHandler 所實作的類別。
2. 輸出不會產生網頁內容 (例如下載檔案時使用的 Response.BinaryWrite，同時會設定 Content Type 和 Content Disposition)。

 

4.使用一系列session管理用戶連接狀態

原文：
這種方法在ASP裏被濫用. 在ASP.NET環境下, 正確的做法應該是設計一個類.
結構化地保存資料. 將對session或者cookie的訪問封裝起來.

我的看法：

用 Session 管理資料庫連接是非常不智的作法，尤其是不遵守 “用完即關”的資料庫連線原則，但如果不用 Session 但使用類別仍沒有遵守用完即關的原則，那寫在類別中仍然沒有意義。因此遵守規則要列為第一要務，其次才是由專屬的資料存取層 (DAL) 來負責，這樣可以將資料存取和使用者介面間的責任做很明確的劃分，而不是像以前 ASP 時代什麼都攪在一起的情況。

5.使用session驗證身份

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

我的看法：

同意，但我同意是基於 “Session 不應濫用”的原則，因為 Session 如果過份使用，對伺服器上的記憶體使用是很傷的，伺服器上的記憶體應保留給應用程式，資料庫，系統和快取來使用，而不是記一堆可能用不到的物件資料。

6.使用Response.Redirect重定向頁

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

我的看法：

這要看應用程式的功能和設計，Response.Redirect 對於清除瀏覽器的表單快取有很明顯的作用，可以避免因為使用者按 F5 導致的重覆資料輸入問題，但我同意原文中不應以頁為程式單元設計的觀點。

7.使用太多ASPX頁

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

我的看法：

這點也是要看情況。因為如果 ASP.NET 單頁的功能過多，勢必要維護的 ViewState 也會很大，這會讓網頁下載的效能受到嚴重影響。
若單頁的責任太多，適當的切割反而有助於應用程式的效能以及責任的釐清，在維護上也會比較清楚。

8.在多個邏輯單元之間複製代碼並修改相應邏輯

原文：
重用. 重用. 重用. 處理此類問題的原則是不出現任何相同或相似的過程.
如果你用上面的方法, 一旦出現重大邏輯更改, 帶來的結果將是災難性的.

我的看法：

這是 copy/paste 的最大潛在問題，不僅是 ASP.NET，任何程式都應避免用這樣的作法，除非程式無法很明確或不易物件化 (ex: JavaScript)。

9.害怕使用DataSet.

原文：
很多人被DataSet嚇壞了. 認為”肯定”影響性能. 但連最初的嘗試都不敢.
他們總認為他們的產品一定重大, 設計上應該”慎重”. 他們往往使用ArrayList或 者設計低級的類來保存集合資料.
進行艱難的資料倒入工作.

我的看法：

這部份我和原著持相反的意見，我不認為 DataSet 應該廣為使用，而是最好別用。因為 DataSet 本身是弱型別的容器，雖然有 Typed DataSet 這種東西，但它相對於一般的 DTO (Data Transfer Object) 或類別物件，DataSet 顯然十分笨重，且相當佔據記憶體，所以 DataSet 不應常用，反而要限縮使用它的情境。

但我也極度不建議在程式中使用過多弱型別 (weak type) 的集合物件，像 ArrayList 這種，在 .NET 2.0 以上的版本，請務必改用泛型集合物件 (Generic Collection)，這可以降低在程式內的 Boxing-Unboxing 轉換所消耗的效能。

10.對“性能”過多註意.

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

我的看法：

原文寫的不清不楚，沒辦法下 comments。不過連接資料庫次數少一點確實有助於效能，ViewState 只能靠降低頁面功能來減少它的大小。

11.應用程式根目錄很亂.

原文：
ASP.NET是開發專案. 不是網站. 應該把不同的資源分類放置.
例如把所有靜態資源(樣式表, 腳本, 圖像)組織到一起. 甚至可以寫一組API來管理他們.
ASPX應該放在一起. ASCX應該放在一起. .*.cs呢? 應該把他們放到另外一個project裏.

我的看法：

這要看專案，分門別類是好事，但每個團隊有自己的作法，遵照自己團隊的作法即可。

12.不厭其煩的寫訪問資料庫的過程

原文：
應該把這工作交給DataAccess Application Block. 你自己還要開關connection, 何苦呢.

我的看法：

如果有可用的 DAL 套件可用 (ex: Entity Framework, Spring.NET)，當然也是可以，現在這種 DAL 不難找，但如果是初學者，透過自己撰寫 ADO.NET 程式來練習和感覺資料庫的 connectivity，會比一開始就只用套件要來的好。

13.自己寫的東西最靠得住.

原文：
事實往往正好相反. 多註意使用人家寫好的產品. 又不收你錢, 何苦那麼愛面子呢.

我的看法：

1. 如果搞得懂的話，用 Open Source 或是 MIT License 這種免費又可以自由轉散布的程式當然可以。
2. 不收你錢但收公司錢的套件，請先問公司允不允許你用，因為公司未必會想因為你好用而花個幾萬去買 License (商用軟體元件都不便宜)。

14. 胡亂命名ASPX檔案名

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

我的看法：

這是 Coding Standard 要求的事，可以參考本文。

15.從來不作繼承或派生

原文：
一些具有相同行為的類, 應該從公共的基類派生出來.
實際意義上, 我們的ASPX應該有一個基類PageBase. 因為總有一些公共的特性需要抽象出來.

我的看法：

必要時，確實要以 Page Base Class 來實作一些共用的功能，要在頁面中實作責任切割的話，繼承介面是必要的。

16.零property

原文：
他們的類(ASPX所對應)裏只有private method.
不公開自己的任何秘密. 可以這一定是JAVA的遺老幹的事.

我的看法：

在一般的 aspx 中確實用不到 Property，會用到 Property 的會是在頁面有資料要繫結到網頁上 (使用 binding 語法) 時才用的到，但 ascx 就最好要有，因為 ascx 必須要用 Page.LoadControl() 才可以載入，而不是只 new 起來就可以，所以不能用在 constructor，而是要額外使用屬性或是設值用的函式。

17. 零ASCX

原文：
不用說, 他還沒學會ASP.NET

我的看法：
快學好 ASCX。

18.使用DreamWeaver“畫“ASPX

原文：
這批人是美工. 甚至有一些人在非常陶醉地討論如何更好地“整合“DreamWeaver和Visual Studio.

我的看法：

請不要懷疑，還是有很多美術設計人員愛用 Dreamweaver 去寫 ASP.NET 網頁，但如果你是程式設計師，請把 Dreamweaver 丟了吧，或是只用 Dreamweaver 設計 HTML 而不是 ASP.NET 網頁，因為 Dreamweaver 會加入一些 Visual Studio 不認識的東西。

19.只熟悉System.Web.UI.WebControl和System.Data.SqlClient

原文：
應該還有一些值得熟悉的類庫.

我的看法：

要寫好 ASP.NET，除了 System.Web.UI.WebControls 和 System.Data.SqlClient 以外，還有一大票的 assembly 和 namespace 夠你研究的，所以不要只侷限於那兩個 namespace。

20.零註釋

原文：
這些都是心裏很明白的快手. 一任IDE生成的缺省註釋橫在那裏不管.

我的看法：

註釋對後續的維護很重要，這也會訂在 coding standard 內，必須遵守。

後面 21, 22, 23 是該文作者自己加的，我就不 comment 了。