数据访问技术

原创 2005年04月29日 11:13:00

数据访问技术

 

大多数应用程序都需要某种形式的数据访问。如果要创建新的应用程序,有三种极好的数据访问方式可供选择:ADO.NETADO OLE DB。如果需要修改现有应用程序的数据访问方式,为了便于维护,可以继续使用该应用程序的当前数据访问技术。但是,如果希望应用程序有较长的生命周期,则应考虑重新设计以对托管应用程序使用 ADO.NET 或对本机应用程序使用 ADO。从长远来看,较新的数据访问技术通常能够减少开发时间,简化代码并提供良好的性能。

ADO.NET介绍

ADO.NET 是重要的应用程序级接口,用于在 Microsoft .NET 平台中提供数据访问服务。在 ADO.NET 中,可以使用新的 .NET Framework 数据提供程序来访问数据源。这些数据提供程序包括:

l         SQL Server .NET Framework 数据提供程序。

l         OLE DB .NET Framework 数据提供程序。

l         ODBC .NET Framework 数据提供程序。

l         Oracle .NET Framework 数据提供程序。

这些数据提供程序可以满足各种开发要求,包括中间层业务对象(它们使用与关系数据库和其他存储区中的数据的活动连接)。

ADO.NET 是专为基于消息的 Web 应用程序而设计的,同时还能为其他应用程序结构提供较好的功能。通过支持对数据的松耦合访问,ADO.NET 减少了与数据库的活动连接数目(即减少了多个用户争用数据库服务器上的有限资源的可能性),从而实现了最大程度的数据共享。

ADO.NET 提供几种数据访问方法。在有些情况下,Web 应用程序或 XML Web services 需要访问多个源中的数据,或者需要与其他应用程序(包括本地和远程应用程序)进行互操作,或者可受益于保持和传输缓存结果,这时使用数据集将是一个明智的选择。作为一种替换方法,ADO.NET 提供数据命令和数据读取器以便与数据源直接通信。使用数据命令和数据读取器直接进行的数据库操作包括:运行查询和存储过程、创建数据库对象、使用 DELETE 命令直接更新和删除。

ADO.NET 还通过对分布式 ADO.NET 应用程序的基本对象“数据集”(Dataset) 支持基于 XML 的持久性和传输格式,来实现最大程度的数据共享。数据集是一种关系数据结构,可使用 XML 进行读取、写入或序列化。ADO.NET 数据集使得生成要求应用程序层与多个 Web 站点之间进行松耦合数据交换的应用程序变得很方便。

因为数据集被远程处理为 XML 形式,所以任何两个组件都可共享数据并使用 XML 架构来定义数据集的关系结构。而且,因为数据集的序列化格式是 XML,所以 DataSet 对象可轻松穿过防火墙,而不受任何限制。除了从 XML 加载数据以外,数据集还可用 SQL Server 中的数据以及通过 OLE DB 公开的数据源中的数据来填充,并可保存对这些数据的更改。

数据集的一个主要特性是可用两种方式访问和操作本地数据集内的数据:

●作为关系数据库中的表   数据集可以包含一个表或表的集合。数据集的一个重要特征是,它会跟踪其所包含的表之间的关系,就好像它是内存中的关系数据存储区。

●作为 XML(可扩展标记语言)结构   数据集中的数据还可按照 XML 数据的形式访问。提供了完成以下操作的方法:以 XML 形式读取和写入数据;以 XML 架构形式读取和写入数据集的结构。此外,为了允许进行同步查看、查询和修改 XML 形式的数据,可将 XmlDataDocument 与数据集相关联。

 

数据访问策略与建议

ADO.NET 假定一个用于数据访问的模型:您在其中打开一个连接,获取数据或执行操作,然后关闭该连接。ADO.NET 为使用此模型提供两个基本的策略。一个模型是在数据集中存储数据,这是断开与数据源的连接时您可以使用的记录的内存中缓存。若要使用一个数据集,您可以创建该数据集的实例,然后使用数据适配器从数据源填充它。然后您可以使用数据集内的数据,例如,通过将控件绑定到数据集成员。

另一个策略是直接对数据库执行操作。在此模型中,可使用包含 SQL 语句或对存储过程的引用的数据命令对象。然后可以打开一个连接,执行命令以执行操作,接着关闭连接。如果该命令返回结果集(即如果该命令执行 Select 语句),则可以使用数据读取器获取数据,数据读取器的功能类似于高效的只读游标。数据读取器然后作为数据绑定的来源。

每一策略都具有特定的优点,您应基于您的数据访问要求选择策略。

1)将数据存储在数据集内

Visual Studio .NET 应用程序中数据访问的常见模型是在数据集中存储数据并使用数据适配器读取和写入数据库中的数据。(.NET 应用程序使用“.NET Framework”:公共语言运行库和托管类。)数据集模型的优越性有:

●使用多个表   一个数据集可以包含多个结果表,它将这些表作为离散对象维护。您可以单独使用这些表或作为父子表在它们之间导航。

●操作来自多个源的数据   数据集内的表可表示来自多个不同源的数据,例如来自不同数据库、XML 文件、电子表格等的数据,都可出现在同一个数据集中。数据在数据集内以后,您可以操作数据并以同种格式关联数据,就好像它们来自单个源。

●在分布式应用程序中的层间移动数据   通过在数据集内保存数据,您可以方便地将它在应用程序的表示层、业务层和数据层之间移动。

●与其他应用程序进行数据交换   数据集提供一种功能强大的数据交换方式,它可以与您的应用程序的其他组件以及其他应用程序交换数据。数据集包含对许多功能的广泛支持,如将数据序列化为 XML 和读写 XML 架构。

●数据绑定   如果正在使用窗体,将控件绑定到数据集内的数据通常比执行命令后以编程方式将数据值加载到控件方便。

●维护记录以供重复使用   通过数据集,您无需再次查询数据库即可重复使用相同的记录。使用数据集功能,您可以对记录进行筛选和排序,并且可以将数据集用作数据源(如果您正在分页)。

●便于编程   当使用数据集时,可以生成一个将其结构表示为对象的类文件(例如,数据集内的 Customers 表可以作为 dataset.Customers 对象访问)。这使得用它编程更容易、更清楚也更不易出错,并且受到智能感知、“数据适配器配置向导”等 Visual Studio 工具的支持。

 

2)直接执行数据库操作

您还可以直接与数据库交互。在此模型中,可使用包含 SQL 语句或对存储过程的引用的数据命令对象。然后您可以执行命令以执行该操作。如果该命令返回结果集(即如果该命令执行 Select 语句),则可以使用数据读取器获取数据,数据读取器的功能类似于高效的只读游标。

安全说明   当使用 CommandType 属性设置为 Text 的数据命令时,请对从客户端发送过来的信息进行仔细检查,然后再将它传递给数据库。恶意用户可能会试图发送(插入)修改过的或其他 SQL 语句,以获得未经授权的访问或破坏数据库。在将用户输入内容传输到数据库之前,应始终确认这些信息是有效的。如果可能的话,请始终使用参数化查询或存储过程,这是最佳措施。

直接执行数据库操作具有特定的优点,这些优点包括:

●额外功能   如前所述,有一些操作只能通过执行数据命令完成,如执行 DELETE 命令。

●对执行的更多的控制   通过使用命令和数据读取器(如果您正读取数据),您可以对如何和何时执行 SQL 语句或存储过程以及哪些将成为结果或返回值进行更多的控制。

●更少的系统开销   通过直接在数据库中读写,您可以不必在数据集内存储数据。由于数据集需要内存,因此可以减少应用程序中的一些系统开销。当您打算只使用数据一次(如在 Web 页中显示搜索结果)时尤其如此。在这种情况下,显示数据时可能不需要创建和填充数据集这一步。

●某些情况下编程更少   在少数情况下(尤其是 Web 应用程序),保存数据集状态需要额外编程。例如,在“Web 窗体”页中,每个往返过程都重新创建页面;除非添加编程来保存和还原数据集,否则每个往返过程也都会放弃并重新创建数据集。如果您使用数据读取器直接从数据库读取,则可以避免管理数据集所需的额外步骤。

由于 Web 应用程序的无状态特性以及与存储数据集关联的相应问题,有时在 Web 应用程序中直接对数据库进行操作更实用。

访问数据建议:

1Web 窗体

通常是使用数据命令;若要获取数据,则使用数据读取器。因为每次 Web 窗体页进行往返过程时都重新创建该页及其控件和组件,所以每次都创建并填充数据集通常是效率低下的,除非您还想要在往返过程间将数据集放入缓存。

在以下情况下使用数据集:

您想要使用多个单独的表或来自不同数据源的表。

您正与其他应用程序或诸如 XML Web services 之类的组件交换数据。

您需要通过从数据库获取的每一记录进行全面的处理。如果您使用数据命令和数据读取器,则您一边读取每一记录一边处理它可能导致连接长期保持打开状态,这可能影响您的应用程序的性能和可缩放性。

如果数据处理涉及相互依赖的记录(例如,在相关表中查找信息)。

如果您想要执行 XML 操作,例如数据上的 XSLT 转换。

如果您喜欢数据集所提供的简便的编程方式。

 设计 Web 应用程序中的数据访问时,您要做出多种选择,例如与数据源通信的方式、是否在页的往返过程之间存储数据、以及如果确实要存储数据应存储在何处等。您所做的选择可以确定应用程序的运行效率及其缩放的良好程度。没有一个数据访问策略是适合于所有情况的。实际上,每一种选择都有其自身的优缺点,您将需要了解这些优缺点。

2XML Web services

XML Web services ASP.NET Web 应用程序,因此使用与 Web 窗体页相同的模型:每次对其进行调用时创建和放弃 XML Web services。这暗示 XML Web services 的数据访问模型大体上与用于 Web 窗体的数据访问模型相同。但是,XML Web services 通常是中间层对象,并且其主要用途通常是与 Web 上的其他应用程序交换数据。

在以下情况下使用数据集:

您的 XML Web services 发送和接收数据;例如,将数据作为方法的返回值发送并将数据作为方法参数接收。这在 XML Web services 中是基本选择;即使出于其他原因您可以考虑使用数据命令,但与其他组件的数据交换几乎始终意味着您应使用数据集。

出于上面列出的适合于 Web 窗体的任何原因。

在以下情况下请使用数据命令(并在适当时使用数据读取器):

XML Web services 正检索标量值。

XML Web services 正执行非查询操作,例如 DELETE 命令。

XML Web services 正调用存储过程以在数据库内执行逻辑。

3Windows 窗体

一般而言,在 Windows 窗体中使用数据集。Windows 窗体通常用于胖客户端,在其中每一用户操作不创建和放弃窗体(及其数据),这与 Web 窗体相同。Windows 窗体应用程序传统上还提供有益于维护记录缓存(例如逐一在窗体中显示记录)的数据访问方案。

具体而言,在以下情况下请使用数据集:

如果您正重复使用相同的记录,例如允许用户在记录间导航。

如果您正使用 Windows 窗体数据绑定结构,该结构是为使用数据集而专门设计的。

出于在上面的 Web 窗体下列出的其他任何原因。

在以下情况下请使用数据命令(并在适当时使用数据读取器):

如果您正从数据库获取标量值

如果您正执行非查询操作,如 DELETE 命令。

如果您正在获取只读数据以显示在窗体中,例如,创建报表。另需注意的是,如果不需要在访问数据后保持数据可用,则使用数据命令。

 

Web 数据访问策略

设计 Web 应用程序中的数据访问时,您要做出多种选择,例如与数据源通信的方式、是否在页的往返过程之间存储数据、以及如果确实要存储数据应存储在何处等。您所做的选择可以确定应用程序的运行效率及其缩放的良好程度。没有一个数据访问策略是适合于所有情况的。实际上,每一种选择都有其自身的优缺点,您将需要了解这些优缺点。

(1)数据集还是直接访问和数据阅读器?

一项重要的选择是要将记录缓存在数据集中还是直接访问数据库并使用数据阅读器读取记录。对于某些数据库操作(如创建和编辑数据库结构),不能使用数据集。例如,如果想从应用程序内创建一个新的数据库表,则不能使用数据集来完成;而应执行一条数据命令。但对于一般的数据访问,常常有将记录存储在断开连接的数据集内和使用数据命令直接操作数据库两种方法可供选择。

每一种策略都具有适用于任何数据访问方案(而不只是 Web 窗体页)的内在优点。例如,数据集简化了对相关表的处理以及对来自完全不同的源的数据的处理。另一方面,使用数据阅读器通常会略微地提高性能和内存使用率,它消除了填充数据集的额外步骤(和内存要求),并使您能够更直接地控制所使用的语句或存储过程。

(2)Web 窗体页中的数据集和数据命令

当使用 Web 窗体页时,有一些附加的因素会影响到是使用数据集还是使用数据阅读器的决定。一个重要因素就是页生命周期(由每一往返过程初始化、处理、然后放弃 Web 窗体页的过程)。如果只是想要在页上显示数据,则创建数据集、填充数据集、然后将控件绑定到数据集的这一过程可能意味着不必要的系统开销,因为该数据集将被立即放弃。在许多情况下,更为有效的方法使用数据阅读器获取数据并在运行时将控件绑定到该数据。

(3)保存数据集还是每次重新创建?

如果您选择使用数据集,您的下一个选择就是确定是否要通过每一往返过程重新创建该数据集。有两个选择:

每次处理页时,都创建数据集的实例并填充它。在完成页处理并将该页发送到浏览器后,放弃该数据集。

只创建和填充一次数据集(通常是在该页第一次运行时)。然后采用某种方式保存该数据集,这种方式允许您通过以后的每次往返过程来检索它。

每次创建数据集意味着通过每一往返过程(实际上是每次用户单击页上按钮时)对数据源执行查询或存储过程。例如,您可能具有一个 Web 窗体页,用户希望在该页中逐页查看数据。如果您每次创建该数据集,则 Web 窗体页对数据源执行查询以获取下一组要显示的记录。

(4)在服务器上缓存还是在客户端上缓存?

如果您决定在往返过程之间保存数据集,则您必须决定在哪里保留它。此问题是 Web 窗体页中状态维护的标准问题之一:在往返过程间要在哪里存储您要保留的信息?有两个选择:

在服务器上,以会话状态、应用程序状态或使用缓存保存数据集。

在客户端上(也就是说,在页中)使用视图状态或通过将数据放置到您自己的隐藏域中来保存数据集。(视图状态也使用隐藏域实现。)

在服务器上存储数据集使用服务器资源。如果存储过多的数据(大型数据集,或者许多用户存储多个小数据集),这可能会影响服务器的性能和可缩放性。使用缓存可以部分弥补这一问题,因为在服务器需要内存或缓存的数据过期时,缓存管理器将放弃该数据集。但因为并不确保数据集处于缓存中,所以必须向页中添加逻辑以检查在缓存中该数据集是否可用;如果不可用,则必须重新创建该数据集并将副本放回到缓存中。

在页中存储数据意味着不需要服务器资源来存储数据。但是,该数据将成为此页的 HTML 流的一部分。如果数据集较大,可能会显著影响将该页加载到用户的浏览器以及将该页回发到服务器所花的时间。

 

 

系统结构设计

 

N层的应用软件系统,由于其众多的优点,已经成为典型的软件系统架构,也已经为广大开发人员所熟知。在一个典型的三层应用软件系统中,应用系统通常被划分成以下三个层次:数据库层、应用服务层和用户界面层。如下图所示:

 

为了使应用服务层的设计达到最好的效果,我们通常还需要对应用服务层作进一步的职能分析和层次细分。很多开发者在构建应用服务层的时候,把数据库操纵、业务逻辑处理甚至界面显示夹杂在一起,或者,把业务逻辑处理等同于数据库操纵,等等,这些,都是有缺陷的做法,所以把用户层分为用户界面层和业务逻辑层:

用户界面层(表现层):位于客户端,Web浏览器展示出来

业务逻辑层:务逻辑表现为对象之间的交互,通过接口响应表现层发出的请求,根据业务逻辑调用相应的业务处理。

应用服务层分为数据操层和事务处理层:

数据操作层:基于数据库最直接的数据库事务处理,数据库事务处理方式是调用ADO.NET

事务处理层:使用基于数据操作层的处理服务,主要任务是实现对数据表的查询、新增、修改、删除等事务处理工作。如果是远程需要调用WebService

数据操作

事务处理

用户界面

数据库

用户界面

业务逻辑

 

 

应用服务层设计的原则

应用服务层的设计,必须遵循的最重要的原则就是高内聚和低耦合。软件分层的本来目的,就是提高软件的可维护性和可重用性,而高内聚和低耦合正是达成这一目标必须遵循的原则。尽量降低系统各个部分之间的耦合度,是应用服务层设计中需要重点考虑的问题。

内聚和耦合,包含了横向和纵向的关系。功能内聚和数据耦合,是我们需要达成的目标。横向的内聚和耦合,通常体现在系统的各个模块、类之间的关系,而纵向的耦合,体现在系统的各个层次之间的关系。

系统的框架,通常包含了一系列规范、约定和支撑类库、服务。

具备的特性:

     系统的内聚和耦合度  

这是保证一个系统的架构是否符合软件工程原则的首要标准。

      层次的清晰和简洁性  

系统每个部分完成功能和目标必须是明确的,同样的功能,应该只在一个地方实现。如果某个功能可以在系统不同的地方实现,那么,将会给后来的开发和维护带来问题。

系统应该简单明了,过于复杂的系统架构,会带来不必要的成本和维护难度。在尽可能的情况下,一个部分应该完成一个单独并且完整的功能。

     易于实现性

如果系统架构的实现非常困难,甚至超出团队现有的技术能力,那么,团队不得不花很多的精力用于架构的开发,这对于整个项目来说,可能会得不偿失。简单就是美。

      可升级和可扩充性

一个系统框架,受设计时技术条件的限制,或者设计者本人对系统认识的局限,可能不会考虑到今后所有的变化。但是,系统必须为将来可能的变化做好准备,能够在今后,在目前已有的基础上进行演进,但不会影响原有的应用。接口技术,是在这个方面普遍应用的技巧。

     是否有利于团队合作开发

一个好的系统架构,不仅仅只是从技术的角度来看,而且,它还应该适用于团队开发模型,可以方便一个开发团队中各个不同角色的互相协作。例如,将Web页面和业务逻辑组件分开,可是使页面设计人员和程序员的工作分开来同步进行而不会互相影响。

     性能

性能对于软件系统来说是很重要的,但是,有的时候,为了能让系统得到更大的灵活性,可能不得不在性能和其他方面取得平衡。另外一个方面,由于硬件技术的飞速发展和价格的下降,性能的问题往往可以通过使用使用更好的硬件来获得提升。

ASP.NET数据访问技术.ppt

  • 2016年01月12日 10:58
  • 1.43MB
  • 下载

Java面试--Spring技术要点--Spring数据访问

24  Spring对DAO的支持 Spring对数据访问对象(DAO)的支持旨在简化它和数据访问技术如JDBC,Hibernateor JDO 结合使用。这使我们可以方便切换持久层。编码时也不用担...

数据访问技术文档

  • 2013年06月02日 04:02
  • 52KB
  • 下载

.NET 数据访问技术概述

前言 .NET Framework自2002年发布以来,已经历了十来个年头。相应的,.NET平台上的数据访问技术也在不断发展,从最基础的ADO.NET,到SqlHelper简单帮助类,到DAAB(D...
  • Liekkas
  • Liekkas
  • 2015年07月17日 17:55
  • 434

internet 上的ado net数据访问技术.rar

  • 2009年10月04日 10:32
  • 1.83MB
  • 下载

一致的数据访问技术 ADO.net

  • 2010年12月06日 23:38
  • 344KB
  • 下载

某书——数据访问技术的发展,以及ado.net

随着数据库和编程技术的发展,出现了众多的数据访问技术。 最初的ODBC,开放数据库互连Open Database Connectivity,实现相同的API访问不同类型的数据库。但ODBC包含上千个...
  • lightty
  • lightty
  • 2012年06月02日 15:50
  • 347

精通LINQ数据访问技术第9章

  • 2009年06月27日 21:06
  • 10KB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:数据访问技术
举报原因:
原因补充:

(最多只允许输入30个字)