檢測代碼位置的比較（C#代碼VS存貯過程）

事由：當一個請假單記錄要儲存之前，要檢測較多的條件。其中檢測這個動作可以由三個方面來完成：用戶端、伺服器的C#代碼、資料庫的存貯過程

這個問題一直困擾著我，我的檢測代碼到底寫在哪裡，我只隱約感覺存貯過程可能會更好，於是把檢測內容準備移進存貯過程，但接著就發現更多問題，於是把兩者進行一次比較（僅限於自己目前的能力），看到底是放在哪好。
（用戶端的JS代碼以後再說，因為用戶端完全可以不檢測，或者說用戶端檢測得再多，服務端也是要重複進行檢測的）
                    C#代碼 SQL存貯過程
複用性                中    好
維護-可讀性            好    中
維護-調試             好    差
編程方便性             好    差
測試                 中    好
效能-運行速度          好    中
效能-網路交換量         好    中
面對變化的適應能力       中    差
部署                 好    好
複雜度                好    差
使用者體驗              中    差

複用性：
C#代碼無法在VB6中使用，而存貯過程檢測的邏輯則可以被VB6簡單直接地重複使用後來查了，有C#中產生DLL，讓VB6調用的（要試一個看其複雜度有多少）

http://read.newbooks.com.cn/info/175321.html

維護-可讀性：
注釋功能大家都有，C#中還有程式碼摺疊功能功能，SQL中有直接看到SQL語句的好處，並且不必建立串連、關閉串連等操作，但C#可以通過函數來彌補。如果子程式完善，串連SQL再執行語句獲得傳回值象吃飯一樣簡單，那C#就好過SQL了。

維護-調試：
調試時的變數的查看與修改，以及邊調試邊修改代碼，這些SQL大大不如C#

編程方便性：
主要是指智能提示，代碼格式標準，代碼文法性錯誤，這也是SQL大大不如C#

測試：
如果要對SQL中的存貯過程進行自動化的測試，可以非常容易實現，因為存貯過程關聯得比較小。而對C#中的子程式測試，好象問題蠻多的，包括要構建Session，Request等內容，自己把握小一些。

效能-運行速度：
使用C#檢測條件，不必動到資料庫的，也就不必串連之類的操作（這時忽然想起來，如果不必使用資料庫的檢測，其實JS端就完成了，會不會JS檢驗+存貯過程檢驗=OK），速度會快，而存貯過程的檢測，至少要調用一個串連存貯過程這個動作。
但對於要使用資料庫的資料時，C#的速度一定沒有存貯過程快

效能-網路交換量：
這裡是指如果資料庫與IIS不在同一台伺服器上時的網路交換量，與運行速度結果類似，對於不用串連資料庫的，C#好，對於串連資料庫的，SQL好。

面對變化的適應能力：
變化是指要增加一個檢測條件時，如果入口參數沒有變化，存貯過程只要改一下，就沒事了。C#代碼則是改完代碼，編譯，部署。
如果入口參數有變化，存貯過程一調整，當前操作的使用者就要出錯了。可以通過一定的方案讓存貯過程的入口參數不必調整，方案如下：
我們準備把用戶端傳過來的參數傳給一個存貯過程時發現，最經常變化的就是這些參數的個數，有時多一個，有時少一個，有沒有辦法讓參數恒定。代碼不受參數個數的變化而變化。後來想了一種方法，即把用戶端的參數一古腦兒地扔到一個表中，然後只傳遞記錄的ID給存貯過程，由存貯過程自己去取，取出來設定成具體參數再進行處理。
1、把擷取到的參數儲存到一個表中，甚至，就是一條字串
2、調用存貯過程時，只傳該記錄的ID
3、存貯過程再從該表中擷取資訊
也正是因為這個問題，才想到寫這篇文章的。

部署：
由於我現在知道C#如何部署時不中斷目前使用者，因此對其內容的修改不會有特別的影響，兩者對部署不會差異太大。

複雜度：
如果使用存貯過程，則也是要經過C#代碼這一段傳送，這樣做憑空多了一層，增加複雜度。

使用者體驗：
是指詢問使用者的情況，用存貯過程不容易實現，用C#則相對來說還是方便的。

總結：
比較後，很明顯，我的預感是錯的，C#原來的一些缺點被克服後，對比一下，C#好多了。今後再對複用、自動化的測試、適應變化這三個方面加強一下，就可以義無反顧地在C#中寫入大量的檢測語句了。