实战 .Net 数据访问层 - 19

访问|数据

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

时间: 2024-07-30 13:44:18

实战 .Net 数据访问层 - 19的相关文章

实战 .Net 数据访问层 - 1

访问|数据 实战 .Net 数据访问层 l 特别说明 本篇实战共分23段,非作者有意如此,乃受CSDN发表文章之64K所限. 虽然有几段根本没有达到64K,但估计是HTML Source超过了这个范 围,所以也不得不单独分段(大都是源代码),请大家谅解. 如果有朋友需要完整文档,请发邮件给我: mailto:xuefeng.zhang@bearingpoint.com l 引言 这次的讨论是上一部分"剖析 .Net 下的数据访问层技术"的一个续,但也可独立成章,为突出主题,作者就特意换

实战 .Net 数据访问层 - 23

访问|数据 u 使用现成的框架 Ø 首选当然是.NET Framework即将正式推出的ObjectSpaces! Ø 如果希望Total Solution,Borland ECO就是最佳选择! Ø 其它 n 开源项目推荐使用OPF(国外) n 商业产品推荐使用Grove(国内) u 设计自己的持久层 Ø 如果希望自己设计轮子,那么,最好的参考资料莫过于这篇文章:http://www.ambysoft.com/persistenceLayer.pdf Ø 它山之石,可以攻玉 此处之它山,非J2E

实战 .Net 数据访问层 - 5

访问|数据 代码4:我的Data Entity – 2,Framework中的Data Entity // DafBase:提供大部分应用程序所需的基本Data Entity支持, // 包括Collection,ADO.NET [Serializable()] public abstract class DefBase : IList, IDictionary { protected internal string _typeEntity = EntityType.OBJECT; // Col

实战 .Net 数据访问层 - 11

访问|数据 4. Data Access Logic 讨论Data Access Logic(为了不和Data Access Layer混淆,文中 所有涉及Data Access Logic的部分将全部使用全称描述,DAL仅指Data Access Layer)前,让我们先看一看它的结构示意图: 咦!怎么回事?看上去长得与DAF非常相似嘛!难道这就是作 者"不辞辛劳"单独开辟一个小节来进行"大肆宣传"的Data Access Logic吗? 没错!这就是Data A

实战 .Net 数据访问层 - 12

访问|数据 从这个DalBase很容易看出,Framework Level的支持主要集中 在Cache Management和Distributed Process上面,这也几乎是所 有Data Access Logic都不得不考虑的现实问题(可能在实际项目中, Data Access Logic Level的Distributed Process需求不会很多,大部分 都在Business Logic中直接解决了)! 以下,就让我们看看制造一个真正的Data Access Logic是多么的 方

实战 .Net 数据访问层 - 22

访问|数据 Ok,在结束整个"我的方案"之前,作者最后"献上"一段代 码(是不是有点晕了?),希望能为您的DAF之旅划上一个圆满的句号J 代码17:通过DAF更新数据 // 创建Customer数据访问对象 CustomerDaf daf = new CustomerDaf(); // 创建Customer数据实体对象,设置对象字段值 Customer cust_1 = new Customer(); cust_1.Id = "ALFKI"; c

实战 .Net 数据访问层 - 10

访问|数据 以下是DAF的结构示意图: 是不是看上去还比较简单? 根据以往的经验判断,在这种继承模式下,主要的开发工作全部集中到了DafBase和MyDaf身上,CustomerDaf的任务相对轻松,数据校验或者转换处理也并不是每个方法都需要的J 那么,DAF既然号称Façade,除了满足Façade之必要条件,还要起很好的表率作用,为上面的Data Entity Façade和下面的Data Access Layer作出一个榜样(也是一个桥梁),以下就是作者总结出的4大要素: (1) 所有的数

实战 .Net 数据访问层 - 18

访问|数据 谈了些实现问题,来说说几个题外话: (1) 性能问题:Cache Management能显著提高数据访问效率,但对内存的要求比较高,尤其是在Web Application或Remoting Server这种应用环境下! 所以,这就要求我们应该将"钱"用在"刀刃"上(对内存毫不在乎者除外J),不能乱花钱! 一般,对于系统数据(如:应用 / 模块,组 / 用户 / 权限等)或Lookup Data(如:婚姻状况列举 / 政治面貌列举等),可以考虑放入Cach

实战 .Net 数据访问层 - 16

访问|数据 5. Cache Management 首先说明一点,之所以将Cache Management单列出来,就 是为了要说明数据缓存的重要性!在很多时候,这比撰写Data Access Logic更让人费心,也更令人难以把握. 作者的这个Cache Management实现了进行Data Cache时所 必须考虑的几个问题,虽然还并不完善,但也可在实战中运用了! 以下,就是它的结构示意图: 从图中,可以很明显地看到,这个Cache Management方案 主要由3部分组成:Manage