3.2实体Bean数据存取.doc

J2EE应用框架设计与项目开发 第3章数据存取框架设计 第3章 PAGE 58 PAGE 57 第3章 数据存取框架设计 从本章开始，我们正式进入J2EE应用框架的设计。首先要解决的是J2EE体系结构中的数据存取的问题。在图1.1中，我们把数据源定义为完成业务逻辑所必须访问的企业资源。这些数据源包括：文件系统数据、邮件服务器、企业遗留应用及数据库管理系统（DBMS）等。通常，数据源的性能以及访问数据源的策略将决定一个J2EE应用的性能和可缩放性。所以，作为J2EE设计师，关键任务之一就是在业务对象与数据源之间实现一套高效而简单的访问接口。 在这些数据源中，关系数据库管理系统（RDBMS）是最重要、最主要、应用最广泛的数据源，故此，本章主要针对数据库管理系统进行讨论。 老是提到“框架”这个词语，那么框架的定义究竟是什么呢？在开始数据存取框架设计之前，笔者认为有必要讨论一下框架的概念。 人们经常把MFC、VCL称为开发框架，那么什么是框架（framework）？其实，框架可以定义为一组关系服务的可扩展、可重用的子系统。细化到软件框架就是一组协同工作的类，它们为特定类型的软件构筑了一个可重用的设计。有一个很形象的比喻：“用别人搭好的舞台，你来做表演”。框架就是这其中的舞台。软件框架具备以下特点： 它是一个功能类的集合，类之间可以相互协作，为业务逻辑子系统提供服务。 它包含了具体类和抽象类，这些类定义了标准的接口、对象间的交互作用和系统的相关常量。抽象类可以包含抽象和具体的方法。 为了利用、自定义或扩展框架的服务，通常需要框架的使用者去定义已存在的框架类的子类。 框架中定义好的类只提供给用户自定义的类调用，而从不调用用户自定义的类。 3.1 常见数据库存取访问方式 图3.1在数据存取框架设计之前，先回顾一下目前J2EE开发中几种常见数据库存取访问方式，分析它们的优缺点，只有这样，我们在数据库存取开发中才能更好地定位，避免人云亦云、盲目设计的情况。常见的方式有： 图3.1 （1）在业务逻辑层的类中，直接使用SQL 代码。 如图3.1所示： ① 优点：写代码的效率很高，没有什么条条框框，想用就用。 ② 缺点：SQL代码到处出现在程序的类中，业务逻辑类与数据库访问直接耦合在一起，这意味着任何小改动都将导致原代码的修改。 ③ 结论：对于小型应用程序是可行的，对于企业级的系统，这种在逻辑业务类中写SQL硬代码的方法，将会导致代码难以维护和扩展。这种方式，无论哪种情况，最好不要使用。 （2）SQL代码封装在一个或多个数据代理类中。 如图3.2所示： 图3.2 ① 优点：在业务类和数据库之间加多一层封装，引入数据库访问代理类，使得系统的可维护性、可扩展性大为提高。这种方式应用很广泛，也很有效率。微软的ADO、Borland的BDE都属于这个方式。 ② 缺点：对数据库结构的变动，都会直接影响到数据访问代理类的实现代码，也就是说，程序原代码还必须改动。 （3）不用写SQL代码，对数据库的访问完全通过具有鲁棒性数据持久层来实现。 如图3.3所示： 图3.3 所谓的鲁棒性数据持久层至少要满足下面的条件： 支持关系数据库的高级特性。（如事务、存储过程、游标） 支持对象和关系之间的映射，用户不直接用SQL与数据库交互。 支持多连接，支持数据库连接池。 支持多种体系结构，支持不同厂商的数据库。 ① 优点：应用程序开发人员不需要了解数据库结构，甚至也没必要知道对象是如何保存在数据库的；有利于组织开发大规模的针对关键业务的信息系统；系统的迁植性、可维护性和扩展性好。 ② 缺点：由于对数据库的访问交给了持久层处理，对持久层要求很高。同时，理论上对系统的性能上有些影响。这个访问方式，缺点不是很明显，其难点及关键是如何实现这个鲁棒性数据持久层。 上面，我们列举了常见的3种数据库存取访问方式，那么究竟应用哪种方式比较合适呢？基本上，方式（A）我们是应该避免的；至于方式（B）和（C），这需要根据系统的规模和具体的需求情况来决定。其实，方式（B）和（C）一直都是争论焦点，我们将在下一节重点讨论一下。 在J2EE体系规范中，方式（C）鲁棒性数据持久层其实就是EJB容器管理的实体Bean（CMP）。可以认为，CMP就是为了实现这个鲁棒性持久层而制定的标准规范。开发人员不必在CMP中编写SQL代码，一切和数据库的交互都交由EJB容器去负责。由于J2EE是开放、标准的规范，所以，CMP组件理论上可以在各种支持J2EE的EJB容器与数据库之间移植。 数据存取编程是一个J2EE应用的基石，采取什么样的策略设计、什么样的方式访问，都将直接决定一个应用的成功与否。我有个朋友，他是一个“建筑工程管理系统”的项目经理。他的系统已经上线运行，但问题不少：响应慢、运行不稳定、容易死机等等