11.6 技术解惑
11.6.1 和ADO以及其他数据访问组件相比,ADO.NET的优势是什么
和ADO以及其他数据访问组件相比,ADO.NET的优势体现在如下5个方面。
1.互操作性
ADO.NET应用程序可以利用XML的灵活性和广泛接受性。由于XML是用于在网络中传输数据集的格式,因此可以读取XML格式的任何组件都可以处理数据。实际上,接收组件根本不必是ADO.NET组件。传输组件可以只是将数据集传输给其目标,而不必考虑接收组件的实现方式。目标组件可以是Visual Studio应用程序或无论用什么工具实现的其他任何应用程序。唯一要求的是接收组件能够读取XML。作为一项工业标准,XML正是在遵循这种互操作性的情况下设计的。
2.可维护性
在已部署系统的生存期中,适度的更改是可能的,但由于实现十分困难,所以很少尝试进行实质的结构更改。这是很遗憾的,因为在事件的自然过程中,这种实质上的更改会变得很有必要。例如,当已部署的应用程序越来越受用户欢迎时,增加的性能负荷可能需要进行结构更改。随着已部署的应用程序服务器的性能负荷的增长,系统资源会变得不足,并且响应时间或吞吐量会受到影响。面对该问题,软件设计者可以选择将服务器的业务逻辑处理和用户界面处理划分到单独计算机上的单独层上。实际上,应用程序服务器层将替换为两层,这就缓解了系统资源的缺乏。
该问题并不是要设计三层应用程序。相反,它是要在应用程序部署以后增加层数。如果原始应用程序使用数据集以ADO.NET实现,则该转换很容易进行。当用两层替换单个层时,将安排这两层交换信息。由于这些层可以通过XML格式的数据集传输数据,所以通信相对较容易。
3.可编程性
Visual Studio中的ADO.NET数据组件以不同方式封装数据访问功能,帮助用户加快编程速度并减少犯错概率。例如,数据命令提取生成和执行SQL语句或存储过程的任务。同样,由这些设计器工具生成的ADO.NET数据类导致类型化数据集,这又可以通过已声明类型的编程访问数据。
4.性能
对于不连接的应用程序,ADO.NET数据库提供的性能优于ADO不连接的记录集。当使用COM封送在层间传输不连接的记录集时,会因将记录集内的值转换为COM可识别的数据类型而导致显著的处理开销。在ADO.NET中,这种数据类型转换则没有必要。
5.可伸缩性
因为Web可以极大增加对数据的需求,所以可缩放性变得很关键。Internet应用程序具有无限的潜在用户供应。尽管应用程序可以很好地为十几个用户服务,但它可能不能向成百上千个(或成千上万个)用户提供同样好的服务。使用数据库锁等资源的应用程序不能很好地为大量用户服务,因为用户对这些有限资源的需求最终将超出其供应。
ADO.NET通过鼓励程序员节省有限资源来实现可缩放性。由于所有ADO.NET应用程序都使用对数据的不连接访问,因此它不会在较长持续时间内保留数据库锁或活动数据库连接。
11.6.2 如何选择DataReader/DataSet
在决定应用程序应使用DataReader还是使用DataSet时,应首先考虑应用程序所需的功能类型。通过DataSet 可执行的操作如下。
- 在应用程序中将数据缓存在本地,以便可以对数据进行处理。如果只需要读取查询结果,则DataReader是更好的选择。
- 在层和层之间,或从XML Web服务对数据进行远程处理。
- 与数据进行动态交互,例如绑定到Windows窗体控件或组合并关联来自多个源的数据。
- 对数据执行大量的处理,而不需要与数据源保持打开的连接,从而将该连接释放给其他客户端使用。
如果不需要DataSet所提供的功能,则可以通过使用DataReader以只进、只读方式返回数据,这样可以提高应用程序的性能。虽然DataAdapter使用DataReader来填充DataSet的内容,但使用DataReader可以提升性能,因为这样可以节省DataSet所使用的内存,并将省去创建DataSet并填充其内容所需的处理。
11.6.3 在数据库中的E-R图
在数据库体系中,概念模型这一概念比较重要。概念模型是对信息世界的建模,它可以使用E-R图来描述世界的概念模型。E-R图提供了表示实体型、属性和联系的方法。
- 实体型:用矩形表示,框内写实体名称。
- 属性:用椭圆表示,框内写属性名称。
- 联系:用菱形表示,框内写联系名称。
图11-16所示为实体-属性图。
图11-16 实体-属性图
图11-17所示为实体-联系图。
图11-17 实体-联系图
11.6.4 三层架构
在使用C#开发Web项目时,当前被无数次证明最好用、最合适的模式是三层架构。C#的三层分别是表示层、业务逻辑层和数据访问层。另外,还有一个Models实体类辅助层。层层调用,实现三层架构,各为其事、各尽其责,这样做层次更加分明,结构更加合理。
- 表示层:为用户提供交互操作界面,这一点不论是对于Web还是WinForm都是如此。这一层主要负责与用户的数据交互和数据展示,并进行简单的数据合法性验证,如非空验证等。
- 业务逻辑层:负责关键业务的处理和数据的传递。复杂的逻辑判断和涉及数据库的数据验证都需要在此层做出处理,如用户注册功能中验证该注册账号是否已经存在。
- 数据访问层:见名知意,负责数据库数据的访问。该层主要为业务逻辑层提供数据。
为了整个项目的开发方便,这3层的3个工程有着一定的命名规则。例如现在有一个项目MyBookShop。为了清晰命名,可以这样命名这个3个工程(即在解决方案中添加的类库)。
- 业务逻辑层(BusinessLogicLayer):MyBookShopBLL,命名空间默认设置为MyBook- Shop.BLL。
- 数据访问层(DataAccessLayer):MyBookShopDAL,命名空间默认设置为MyBookShop.DAL。
另外,为了传递数据方便,通常再添加一个类库,这个类库是贯穿于整个三层架构中的,即实体类。现假设这个类型命名为MyBookShopModels,命名空间默认值设置为MyBookShop.Models。其中封装的每个类都对应一个实体,通常就是数据库中的一个表。例如,如数据库中的用户表(Users)封装为(UserModel),将表中的每个字段都封装成共有的属性。
这样三层架构的搭建就基本完成了,这3层有着非常强的如下依赖关系。
表示层←业务逻辑层←数据访问层
它们之间的数据传递是双向的,并且通常借助实体类传递数据。那么三层架构都有哪些优点呢?具体说明如下。
- 易于项目的修改和维护。在项目的开发过程中或者开发后的升级过程中,甚至在项目的移植过程中,这种三层架构都是非常方便的。例如,项目从Web移植到Form,只需要将表示层重新做一遍就可以了。其余两层不用改动,只需添加到现有项目中就可以了。如果不采用这种架构,只是将代码写到表示层。那么所有的编码几乎都要重新编写。
- 易于扩展。在功能的扩展上同样如此,如有功能的添加,只需在原有的类库中添加方法即可。
- 易于代码的重用。
11.6.5 ADO.NET起了一个接口的作用
其实可以将ADO.NET看做是一个连接程序和数据库的接口其作用相当于水龙头,如图11-18所示。我们不用考虑它在内部是如何实现的,只须记住使用接口连接程序和数据库的方法就可以了。
图11-18 水龙头
作为一名程序员,应根据具体项目的情况来选择对应提供者的引用指令。例如,如果对移植性的要求比较高,则可以使用通用的ODBC方式;如果系统只是要求对某特定数据库的应用,则可以使用对应种类的.NET数据库提供者。