跟我学统一建模语言UML——MVC体系架构设计模式中的数据访问层的设计原则及示例

1.1跟我学统一建模语言UML——MVC体系架构设计模式中的数据访问层的设计原则及示例

1.1.1MVC体系架构设计模式中的数据访问层的设计原则及示例

1、数据访问（持久）层的设计目标

（1）为整个软件系统项目提供一个高层、统一、安全和并发的数据持久化实现机制。（2）完成对各种数据进行持久化的编程实现工作，并为软件系统业务逻辑处理层提供对应的数据访问功能服务。

2、为什么要提供数据持久层

（1）数据持久层提供了对软件系统中的数据的访问方法，能够使其它程序员和开发者避免手工编写相关的程序访问数据持久层（Persistene layer），使其更专注于软件系统中业务逻辑的开发，并且能够在不同项目中重用映射框架，大大简化了对软件系统中数据的增、删、改、查等功能的开发过程和功能的实现代码。

（2）而且也不会丧失多层结构的天然优势，继承延续J2EE特有的可伸缩性和可扩展性。

3、各种数据持久层技术应用方案

（1）J2EE中标准的数据持久层架构

Business Layer <-> Session Bean <-> Entity Bean <-> DB

（2）为了解决性能障碍的替代架构

Business Layer <-> DAO <-> JDBC <-> DB

（3）使用Hibernate来提高上面架构的开发效率的架构

Business Layer <-> DAO <-> Hibernate <-> DB

4、上面的三种架构设计方案的对比

（1）内存消耗

采用JDBC的架构无疑是最省系统内存的，而Hibernate框架的架构次之，而基于EJB 的系统架构最差。

（2）运行效率

如果对JDBC的功能实现代码编程的非常优化，那么JDBC架构运行效率将是最高的。但是在实际的项目中，这一点几乎做不到，因为这需要程序员非常精通JDBC及相关的应用技术，并运用Batch语句、调整PreapredStatement的Batch Size和Fetch Size等工作参数，以及在必要的情况下采用结果集的cache等技术。

而一般情况下的程序员是做不到这一点的。因此Hibernate框架的系统架构表现出最快的运行效率，而基于J2EE EJB的体系架构的系统效率会差的很远。

（3）开发效率

在有Eclipse、JBuilder等开发工具的支持下，对于简单的项目，EJB架构开发效率最高，JDBC次之，Hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，Hibernate效率高的惊人，JDBC次之，而EJB架构很可能会失败。

5、软件系统数据访问层的设计

（1）实体类、会话类和数据访问对象类

对数据库系统中的数据访问的编程实现的相关程序类可以分成实体类（Entity Class）、会话类（Session Class）和数据访问（连接）对象类（Data Access Object Class，DAOs）。

通过使用这种数据访问层的模块设计和系统模式的划分，将使得软件系统的程序更加模块化，便于软件系统开发和后期的系统维护。

（2）实体类的作用

实体类是对应于一个数据库表中的记录数据的封装，也就是该程序类的一个对象实例对应于数据库表中的一条记录数据。而且，该程序类中的成员属性和数据库表中的数据记录中的字段是一一对应的（Domain Entity），也可以与数据库表中的结构不完全一一对应（Custom Entity）。

（3）会话类的作用

会话类对应于对一个数据库表中的所有记录的数据操作（也即对实体）。主要为下面的几种类型的操作，而执行下述任务的数据访问方法通常称为“CRUD”方法，这是由各项

任务的首字母组成的一个缩写词：

1)在数据库中创建记录（CREATE）；

2)查找并读取数据库中的记录并把业务实体数据返回给调用程序（READER）；

3)使用调用程序提供的修改后的业务实体数据更新数据库中的记录（UPDATE）；

4)删除数据库中的记录（DELETE）

（4）数据访问（连接）对象类的作用（DAO模式的应用）

为了在系统后台的数据库的数据源发生变化的情况下，尽可能地减少对软件系统业务层、表示层相关程序的改动。对数据库的连接一般采用DAO的设计模式来实现数据库的连接。

下面为数据连接类的程序示例代码：

1.1.2数据访问层中的业务实体组件的设计

1、业务实体（Business entity）

（1）什么是业务实体

业务实体是指在软件系统中实现业务规则的程序对象，也即是客观存在并可区分的事物。

（2）业务实体具有以下的特点

1)业务实体提供对业务数据及相关功能（在某些设计中）的状态编程访问。

2)业务实体可以使用具有复杂架构的数据来构建。这种数据通常来自数据库系统中的

多个相关的数据库表。

3)业务实体数据可以作为软件系统业务过程的部分I/O 参数。

4)业务实体可以是可序列化的对象以保持它们的当前状态。例如，应用程序可能需要

在本地磁盘、本地数据库（如果应用系统要求能够脱机工作）或消息队列消息中存储实体数据。

5)业务实体不直接访问数据库系统，全部数据库访问都是由相关联的数据访问逻辑组

件提供的。

6)业务实体不启动任何类型的事务处理，而事务处理是由使用业务实体的应用程序或

业务过程来启动。

（3）业务实体的表示

软件应用系统从本质上来说是计算机对现实世界的模拟。现实世界中的实体对象，在

软件系统中主要表现为需要处理的数据。而在面向对象的系统中，这是通过“类”和“对象”等程序元素来表示的。因此，在考虑数据实体层的设计策略时，需要把握以下的设计要点：

1）一致的数据表示方式

在一个软件系统中，数据的表示方式必须尽可能统一，同时，在处理单个数据和多个数据时，处理方式要尽可能一致。

2）良好的映射方法

因为数据通常是需要存储到数据库系统中，因此，良好的数据/关系的映射方法是必需的。

3）处理好对象的粒度，即所谓的粗粒度对象、细粒度对象。

2、值对象（Value Object）模式和传输对象模式（DTO---Data Transfer Object）在软件系统项目中的应用

（1）值对象（Value Object）

前面所说的各个业务实体类其实就是值对象（Value Object），因为利用值对象可以封装数据库表或者其它业务数据，同时对成批数据可以采用值对象的集合（如Vector或者ArrayList等集合）来表示。

（2）传输对象模式--DTO

通过减少分布式通信的消息而提高软件系统中数据交换的效率，通常这里所指的通信