** 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 ）！
暂时就想到这些，如有什么遗漏，欢迎大家补充。