ADO.NET实用技巧两则
发布时间:2006-10-14 3:13:30   收集提供:gaoqian

  要想充分发挥ADO.NET的优势,不仅需要全面、深入理解ADO.NET编程模型,及时总结经验、技巧也十分重要。ADO已经有多年的实践经验,ADO.NET以此为基础,提供了更加丰富、强大的工具;尽管如此,ADO.NET的设计目标毕竟不是提供一个即插即用的工具,它不会把所有的编程工作简化到仅靠鼠标点击就可以完成的程度。
  ADO.NET包含了一大堆代表数据访问模型中各种逻辑实体的对象,其中尤以连接、事务这两个对象最为重要。连接的作用是建立一个与后端数据库通信的通道,创建连接对象必须以特定的.NET数据提供者为基础。事务对象可以在已有的连接对象上创建,也可以通过显式地执行一个BEGIN TRAN SQL语句创建。虽然理论很简单,但实际上,围绕连接、事务的不确定因素很多,而且它们对应用整体的稳定性和效率有着至关紧要的影响。

  如何保存连接字符串,保护连接字符串中可能包含的敏感信息(例如密码)?怎样设计一个完善的数据访问策略,既考虑到安全性(即身份验证、授权),却又不至于对性能和可伸缩性造成太大的影响?如果需要用到事务,那么如何高效地实现和控制事务?采用自动事务还是手动事务?在使用ADO.NET时,这些问题都必须仔细考虑。

  一、连接字符串,连接池

  数据库连接是一种重要的、有限的、开销昂贵的资源,因此用好连接对象是任何应用的最基本的要求。使用数据库连接的要点可总结如下:

  保存连接字符串应注意安全。
  打开连接应迟,关闭连接应早。
  连接字符串是访问数据库的钥匙。连接字符串除了说明要访问的数据之外,还包含了用户为什么可以访问那些数据的身份证明。在执行数据库操作时,用户身份证明是确定数据访问权限的最重要的因素。

  1.1 保存连接字符串

  目前,硬编码的连接字符串具有最好的性能,因为它们直接编译进了应用的代码之中。然而,硬编码的字符串影响程序的灵活性,一旦连接字符串改变,应用程序必须重新编译。

  将连接字符串保存到外部提高了灵活性,代价是访问外部字符串需要付出额外的开销。但在绝大多数情况下,由此导致的性能开销可以忽略不计,真正需要担心的是安全问题。例如,攻击者可能修改、窃取连接字符串。将连接字符串保存到外部环境的常见途径有:配置文件,UDL文件,Windows注册表

  .NET框架配置文件以纯文本文件的形式部署,访问方便。如果连接字符串包含密码,文本格式将是最大的缺陷所在,因为密码将以明文的形式保存。可以考虑引入一个专用的加密/解密引擎,不过这部分工作需要开发者自己完成。

  UDL文件是供OLE DB提供者使用的文本文件,也就是说,SQL Server托管提供者不支持UDL文件。UDL文件也存在和前面的配置文件一样的安全问题,总地看来优势不多。

  最后,Windows注册表可以作为一个天然安全的存储场所。注册表是一个保存关键信息的系统知识库,如果结合运用加密技术,可以达到较高的安全性。使用注册表的主要缺点是部署麻烦,要求创建注册键(可能还要执行加密)以及从注册表读取数据。虽然.NET Framework提供了一组调用底层Win32 API的封装类,但这些类都没有提供加密功能。aspnet_setreg.exe工具可以用来创建HKEY_LOCAL_MACHINE下的注册键保存用户名称和密码,例如:aspnet_setreg.exe -k "Software\MyData" -u:userID -p:password。该命令将加密指定的用户ID和密码。

  1.2 连接池原理

  连接池允许我们通过一个缓冲池重用现有的连接对象,避免每次使用连接对象时都要新建一个对象。采用连接池之后,只要少量的连接对象就可以满足大量客户端的需要。

  每一个连接池都与一个独立的连接字符串及其事务上下文关联。每次打开一个新的连接,数据提供者会尝试将指定的连接字符串与连接池的字符串进行匹配。如果匹配失败,数据提供者创建一个新的连接并将它加入连接池。连接池被创建之后,除非进程结束,否则不会被拆除。有人认为这种处理方式会影响性能,其实不然,维护一个不活动的或者空的连接池不需要多少开销。

  连接池创建之后,系统会创建一些连接对象并将它们加入连接池,直至达到额定的最小连接对象数量。以后,系统会根据需要新建和加入连接对象,一直到达最大连接对象数量限额为止。如果程序请求一个连接对象时没有空闲的连接对象可用,且连接池里面的对象数量已达到上限,则请求被放入队列,一旦有连接被释放回缓冲池就立即取出使用。

  避免用编程的方式构造连接字符串。如果通过合并多个输入数据的方式构造出连接字符串,很容易给注入式攻击以可乘之机。如果必须用到用户输入的数据,务必进行严格的验证。

  1.3 关闭连接

  关闭一个连接时,连接对象被返回给连接池以便重用,但这时实际的数据库连接并未被拆除。如果禁用了连接池,则实际的数据库连接也被关闭。这里必须强调的一点时,连接对象使用完毕后应当显式关闭并将它返回给连接池,不要依靠垃圾收集器来释放连接。实际上,当连接对象的引用超出有效范围时,连接不一定被关闭——垃圾收集器的功能是拆除代表物理连接的.NET封装对象,但这并不意味着底层的连接也被关闭了。

  调用Close或Dispose方法可以将连接释放回连接池。只有当生存期结束或出现严重错误时,连接对象才会被从连接池删除。

  1.4 连接池与安全

  如果一个应用程序的所有数据访问操作都使用同样的连接字符串,连接池的优势将发挥到极限。但是,这只是一种理想化了的状况,很可能与应用程序的其他要求存在冲突。例如,如果只使用一个连接字符串,要在数据库这一层次上执行安全控制就很困难了。

  另一方面,如果让每一个用户分别使用自己的连接字符串(即为每一个用户分别设定数据库帐户),势必出现大量小型的连接池,许多连接根本不会被重用。依照惯例,这类问题的最佳解决方案是寻找两个极端之间的一个适当折衷点。我们可以设置一组具有代表性的公用帐户,同时修改存储过程,使之接受一个表示用户标识的参数,存储过程根据传入的用户标识执行不同的操作。

  二、事务模式

  分布式企业应用离不开事务。在数据访问代码中加入事务管理功能主要有两种方式:手动方式,自动方式。

  在手动方式中,程序员负责编写所有配置、使用事务机制的代码。自动(或COM+)事务则在.NET类中加入声明式属性,指定运行时对象的事务特性。自动方式方便了将多个组件配制成在同一个事务之内运行。两种事务方式都支持本地的或分布式的事务,但自动的事务方式极大地简化了分布式事务处理。

  必须注意的是,事务是一种开销很大的操作,所以决定使用事务之前务必再三考虑。如果确实需要使用事务,那就要尽量缩小事务的粒度,减少对数据库的加锁时间、加锁范围。例如,对于SQL Server,单个的SQL语句不需要显式地声明事务,SQL Server会自动将每一个语句作为一个独立的事务运行。手动的本地事务总是比其他事务快得多,因为它不需要涉及DTC(Distributed Transaction Coordinator)。

  手动事务、自动事务应当视为两种不同的、互斥的技术。如果要在单个数据库上执行事务性操作,优先考虑手动事务。当单个事务跨越多个远程数据库,或单个事务涉及多个资源管理器(例如,一个数据库和一个MSMQ资源管理器),优先考虑自动事务。不管怎样,应当极力避免混合运用两种事务模式。如果性能不是特别重要,即使只对一个数据库操作也可以考虑使用自动事务,使代码更加简洁(但速度略慢)。

  总而言之,要提高数据库访问代码的质量,必须深入了解ADO.NET对象模型,根据实际情况灵活运用各种技巧。ADO.NET是一个公用的API,各种应用——不管是Windows窗体应用、ASP页面还是Web服务,都可以通过ADO.NET访问数据库;但是,ADO.NET不是一边接受输入、一边吐出结果的黑箱,而是一个由许多工具组成的工具箱。

 

 
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50