java-DAO分层解析.docxVIP

基本的分层结构： 具体细分： 简单实例分析 使用emp表（基本字段：empno,ename,job,hiredate,sal,comm）实现如下功能（CRUD）： ? 【业务层】实现新雇员的增加操作； |-〖数据层〗雇员编号是由用户自己输入的，所以必须先确定雇员编号是否存在，需要查询 |-〖数据层〗如果雇员编号不存在，则执行增加操作，更新； ? 【业务层】实现雇员的修改操作； |-〖数据层〗直接修改雇员数据 ? 【业务层】实现雇员的删除操作 |-〖数据层〗直接删除雇员数据； ? 【业务层】可以根据雇员编号查询出雇员的完整信息； |-〖数据层〗直接根据编号做限定查询； ? 【业务层】显示全部雇员的记录 |-〖数据层〗查询雇员表的全部数据 ? 【业务层】可以分页显示全部雇员记录，或者可以模糊查询，返回全部记录并需要返回本次查询的总数据量 |-〖数据层〗使用like模糊查询满足条件的数据信息 |-〖数据层〗使用count（）函数统计满足条件的数据量 实际开发从右到左进行： 数据层/业务层/控制层/显示层 DAO设计模式—后台业务层（包括业务层和数据层） 以前的设计操作模式（不推荐使用）： 数据层：又称数据库访问层（Data Access Object，DAO），是专门进行数据库的原子性操作（增删改查）即是需要控制的就是JDBC中的PreparedStatement接口的使用； 业务层：又称为业务对象（Business Object,OB）,又可称为服务层（Service）。业务层核心的目的是调用多个数据层的操作以完成整体的项目的业务设计。 Value Object 不同层次之间一定要进行数据的传递，但是既然要操作的时指定的数据表，所以数据的结构要与表的结构一一对应，即简单的java类（po、to、pojo、vo） （重要！！）在实际的工作之中，针对于简单Java类的开发给出如下的要求： ? 考虑到日后程序有可能出现的分布式应用问题，所以简单Java类必须实现java.io.Serializable ? 简单java类的名称必须与表名称一致 |-有可能采用这样的名字： 表名：student_info 类名：StudentInfo ? 类中的属性不允许使用基本数据类型，都必须使用基本数据类型的包装类 |-基本数据类型的数值型默认值时0，二如果是包装类默认值就是null； ? 类中属性必须用private封装，封装后的属性必须提供setter，getter方法 ? 类中可以定义有多个构造方法，但是必须要保留有一个无参构造方法； ? 【可选要求，基本不用】覆写equals()、toString()、hashCode() 开发数据层： 数据层最终是交给业务层调用的，所以业务层必须知道数据层的执行标准，即：业务层需要明确的知道数据层的操作方法，但是不需要知道它的具体实现。 开发数据层操作标准 不同层之间如果进行访问，那么必须要提供有接口，以定义操作标准。那么对于数据层也是一样的，因为数据层的最终要交给业务层执行，所以需要先定义数据层接口。 对于数据层的接口给出如下的开发要求： ? 数据层既然是进行数据操作的，那么就将其保存在dao包下； ? 既然不同的数据表的操作有可能使用不同的数据层开发，那么就针对于数据表进行命名； |-emp表，那么数据层的接口就应该定义为IEmpDAO； ? 对于整个数据层的开发严格来讲就只有两类功能： |-数据更新：建议它的操作方法以doXxx（）的形式命名，例如：doCreate（）、doUpdate（）、doDelete（） |-数据查询：对于查询分为两种形式： |-查询表中的数据：以findXxx（）形式命名，例如：findById（）、findByName()、findAll() |-统计表中的数据：以getXxx（）形式命名，例如：getAllCount（）。 数据层实现类 数据层需要被业务层调用，数据层需要进行数据库的执行（PreparedStatement），实际中要执行多个数据层的调用，所以数据库的打开与关闭操作应由业务层控制 所有的数据层实现类要求保存在dao.impl子包下。 定义接口：----有业务层处理 定义数据层工厂类---DAOFactory 业务层要想进行数据层的调用，那么必须要取得IEmpDAO接口对象，但是不同层之间要想取得接口，需要使用工厂设计模式，这个工厂类将其保存在factory子包下。 使用工厂的特征就是外层不需要知道具体的子类。 开发业务层 ·业务层是真正留给外部调用的，可能是控制层，或者是直接调用，既然业务层也是有不同的层进行调用，所以业务层开发的首要任务就是定义业务层的操作标准。 开发业务业务层标准----IEmpService 业务层也称为Ser