|
6. ASPECT
AOP（Aspect Oriented Programming）可能是最近幾年被挖掘出
來的最具震撼力的技術之一，作者并不打算在此花什么篇幅介紹它（網上資料已多如牛毛），只是希望借用其ASPECT概念來說明幾個設計Data Access Layer時必須考慮的問題（也是在進行系統架構設計前不得不考慮的幾個重要因素！）：
（1） Security
把它排在ASPECT首位相信大家沒什么疑義吧！
雖然，Business Logic已為我們搞定了太多的Security Issues，但那個長久揮之不去的“ConnectionString陰影”還是會成為不少開發人員心中永遠的“不爽”！
有位同事告訴我，微軟曾有一個號稱8萬人難以攻破的ASP.NET應用程序，它的ConnectionString居然就是存在了Registry中（別忘了禁用Remote Registry服務）！這樣的雙重保護（另一重是對ConnectionString進行加密處理）是多么簡單卻實用啊！
在很多時候，As Simple As Possible才是我們應該真正追求的目標。
另一個需要注意的問題就是如何應對SQL Injection（SQL注入）攻擊！
一個經典的例子如下所示：
string strSql = "select * from user where" +
" username = '" + strUserName +
"' and password = '" + strPassword;
在這里，采用Dynamic SQL本身并無調用上的邏輯問題，但卻給了Cracker以可乘之機：如果系統沒有針對strPassword做過任何數據校驗，當用戶試著輸入“abc”作為username，“123’ or 1 = 1”作為password時，那就不得不遺憾的告訴您：該系統已被成功攻破，請迅速發布新的補丁程序！
雖然這個例子很簡單，但已提醒我們：小小的SQL語句也會成為系統漏洞的“重要來源”！
在這種情況下，避免產生危機的方法也很簡單：使用Stored Procedure或者Parameter Collection（你不會告訴我準備把這個責任推給毫無SQL經驗的Business Logic人員吧J）。如果系統架構時沒有準備采用Stored Procedure或者開發人員很不習慣使用Parameter Collection（坦率地講，我也不喜歡這個東東），那也有個稍微麻煩點的Solution（當然不推薦采用）：
i. 僅使用username拼裝Dynamic SQL；
ii. 判斷返回紀錄數是否為1（假定username為unique column）；
iii. 如果記錄數為1，取出password數據；
iv. 判斷用戶輸入之password是否與查詢返回之password匹配。
限于篇幅，這里只討論了兩個比較常見的問題，當然是遠遠不能覆蓋Security的全部精髓，只是為了表明一個觀點：Security實在是非常非常重要，切勿等閑視之！
（2） Transaction
這是個避無可避的東東，要發現它的問題有一定難度，且不易于測試！作者不準備就此展開，大家只有通過實戰積累經驗了。
另外，到底是用System.EnterpriseServices還是Connection.BeginTransaction + try-catch，依然會使很多.NET開發人員產生困惑，作為系統架構設計的一部分，這也是個必須充分考慮的問題！
（3） Logging
日志不是個要不要的問題，而是怎么做的問題。
Log4Net已經很不錯了，不會還想親自動手做一個吧！
（4） Exception
這是個“無底洞”，看你怎么設計了。
就作者經歷的項目，主要采用這么兩種方式：
i. one throw，one catch，no re-throw
這個最簡單了，不需要太復雜的Exception Inheritance Hierarchy，處理起來也比較輕松；
ii. one throw，multi-catch，multi-re-throw
復雜應用可能采用這種模式更多些，需要一大堆的Exception Classes和令人望眼欲穿的try-catch，但可能在擴展性和容錯處理方面會表現得更為出色（可苦了咱們開發人員L）！
暫時就想到這些，如有什么遺漏，歡迎大家補充。
下一段：http://www.csdn.net/develop/Read_Article.asp?id=27564
| 
