6. ASPECT

AOP（Aspect Oriented Programming）可能是最近幾年被挖掘出

來的最具震撼力的技術(shù)之一，作者并不打算在此花什么篇幅介紹它（網(wǎng)上資料已多如牛毛），只是希望借用其ASPECT概念來說明幾個設(shè)計(jì)Data Access Layer時必須考慮的問題（也是在進(jìn)行系統(tǒng)架構(gòu)設(shè)計(jì)前不得不考慮的幾個重要因素！）：

（1） Security

把它排在ASPECT首位相信大家沒什么疑義吧！



雖然，Business Logic已為我們搞定了太多的Security Issues，但那個長久揮之不去的“ConnectionString陰影”還是會成為不少開發(fā)人員心中永遠(yuǎn)的“不爽”！



有位同事告訴我，微軟曾有一個號稱8萬人難以攻破的ASP.NET應(yīng)用程序，它的ConnectionString居然就是存在了Registry中（別忘了禁用Remote Registry服務(wù)）！這樣的雙重保護(hù)（另一重是對ConnectionString進(jìn)行加密處理）是多么簡單卻實(shí)用�。�

在很多時候，As Simple As Possible才是我們應(yīng)該真正追求的目標(biāo)。



另一個需要注意的問題就是如何應(yīng)對SQL Injection（SQL注入）攻擊！

一個經(jīng)典的例子如下所示：

string strSql = "select * from user where" +

" username = '" + strUserName +

"' and password = '" + strPassword;



在這里，采用Dynamic SQL本身并無調(diào)用上的邏輯問題，但卻給了Cracker以可乘之機(jī)：如果系統(tǒng)沒有針對strPassword做過任何數(shù)據(jù)校驗(yàn)，當(dāng)用戶試著輸入“abc”作為username，“123’ or 1 = 1”作為password時，那就不得不遺憾的告訴您：該系統(tǒng)已被成功攻破，請迅速發(fā)布新的補(bǔ)丁程序！

雖然這個例子很簡單，但已提醒我們：小小的SQL語句也會成為系統(tǒng)漏洞的“重要來源”！



在這種情況下，避免產(chǎn)生危機(jī)的方法也很簡單：使用Stored Procedure或者Parameter Collection（你不會告訴我準(zhǔn)備把這個責(zé)任推給毫無SQL經(jīng)驗(yàn)的Business Logic人員吧J）。如果系統(tǒng)架構(gòu)時沒有準(zhǔn)備采用Stored Procedure或者開發(fā)人員很不習(xí)慣使用Parameter Collection（坦率地講，我也不喜歡這個東東），那也有個稍微麻煩點(diǎn)的Solution（當(dāng)然不推薦采用）：

i. 僅使用username拼裝Dynamic SQL；

ii. 判斷返回紀(jì)錄數(shù)是否為1（假定username為unique column）；

iii. 如果記錄數(shù)為1，取出password數(shù)據(jù)；

iv. 判斷用戶輸入之password是否與查詢返回之password匹配。



限于篇幅，這里只討論了兩個比較常見的問題，當(dāng)然是遠(yuǎn)遠(yuǎn)不能覆蓋Security的全部精髓，只是為了表明一個觀點(diǎn)：Security實(shí)在是非常非常重要，切勿等閑視之！



（2） Transaction

這是個避無可避的東東，要發(fā)現(xiàn)它的問題有一定難度，且不易于測試！作者不準(zhǔn)備就此展開，大家只有通過實(shí)戰(zhàn)積累經(jīng)驗(yàn)了。

另外，到底是用System.EnterpriseServices還是Connection.BeginTransaction + try-catch，依然會使很多.NET開發(fā)人員產(chǎn)生困惑，作為系統(tǒng)架構(gòu)設(shè)計(jì)的一部分，這也是個必須充分考慮的問題！



（3） Logging

日志不是個要不要的問題，而是怎么做的問題。

Log4Net已經(jīng)很不錯了，不會還想親自動手做一個吧！



（4） Exception

這是個“無底洞”，看你怎么設(shè)計(jì)了。

就作者經(jīng)歷的項(xiàng)目，主要采用這么兩種方式：

i. one throw，one catch，no re-throw

這個最簡單了，不需要太復(fù)雜的Exception Inheritance Hierarchy，處理起來也比較輕松；

ii. one throw，multi-catch，multi-re-throw

復(fù)雜應(yīng)用可能采用這種模式更多些，需要一大堆的Exception Classes和令人望眼欲穿的try-catch，但可能在擴(kuò)展性和容錯處理方面會表現(xiàn)得更為出色（可苦了咱們開發(fā)人員L）！



暫時就想到這些，如有什么遺漏，歡迎大家補(bǔ)充。



下一段：http://www.csdn.net/develop/Read_Article.asp?id=27564