关于DAO层设计的学习记录：
1.用户所提出的所有的需求都应该划分为业务层，因为它指的是功能，而开发人员必须要根据业务层来对数据层进行设计
2.在实际的工作之中，针对于简单的java类的开发给出如下的要求：
* 考虑到日后程序可能出现分布式应用问题，所以简单java类必须实现java.io.Serializable接口
* 简单java类的名称必须与表名称一致
student_info ------类名StudentInfo
* 类中的属性不允许使用基本数据类型，都必须使用基本数据类型的包装类
基本数据类型的数值型默认是0，而如果是包装类的默认值就是null
* 类中的属性必须使用private封装，封装后的属性必须提供有setter、getter方法
* 类中可以定义有多个构造方法，但是必须要保留一个无参构造方法
* [可选要求]重写equals()、toString()、hashCode()等
将所有的简单java类保存在vo包中(po,pojo,vo,,)
不管有多少张表，只要是实体表，那么一定要写简单java类，而且不要试图想着一次性将所有的表都转换到位，且都保存在vo包中
3.数据层最终是交给业务层进行调用的，所以业务层必须知道数据层的执行标准，即：业务层需要明确的知道数据层的操作方法，但是不需要知道它的具体实现
业务层--|->数据层--|->数据库
数据层标准 JDBC
3.1开发数据层操作标准
不同层之间如果要进行访问，那么必须提供有接口，以定义操作标准，那么对于数据层也是一样的，因为数据层的最终要交给业务层执行，所以需要先定义数据层接口
对于数据层的接口给出如下开发要求：
* 数据层既然是进行数据操作的，那么就将其保存在dao包下
* 既然不同的数据表的操作有可能使用不同的数据层开发，那么就针对数据表进行命名
emp表，那么数据层的接口就应该定义为IEmpDAO
* 对于整个数据层的开发严格来讲就只有两类功能：【】数据的更新，建议它的操作方法以doXxx()的形式命名，例如doCreate()增加，doUpdate(),doRemove()
【】数据查询，对于查询分两种形式：
查询表中数据：以findXxx()形式命名，例如:findById()、findByName()、findAll()
统计表中的数据：以getXxx()形式命名，例如：getAllCount()得到全部的数据量
必须标注完整注释
4.数据层需要被业务层调用，数据层需要进行数据库的执行(PreparedStatement),由于在开发之中一个业务层要执行多个数据层的调用，所以数据库的打开与关闭操作应该由业务层控制比较合理
所有的数据层实现类要求保存在dao.impl子包下
5.业务层要想进行数据层的调用，那么必须取得IEmpDAO接口对象，但是不同层之间如果想要取得接口对象实例需要使用工厂设计模式，这个工厂类将其保存在factory子包下
使用工厂的特征就是外层不需要知道具体的子类
6.开发业务层
业务层是真正留给外部调用的，可能是控制层，或者是直接调用，既然业务层也是由不同的层进行调用，所以业务层开发的首要任务就是定义业务层的操作标准
6.1开发业务层标准---service
业务层也可以称为service层，既然描述的是emp表的一个操作，所以名称就定义为IEmpService，并且保存在service子包下，但是对于业务层的方法定义并没有明确的要求，只不过个人强烈建议还是写上有意义的同一名称
7.业务层实现类
* 负责控制数据库的打开与关闭，当存在了业务层对象后其目的就是为了操作数据库，即：业务层对象实例化之后就必须准备好数据库连接
* 根据DAOFactory调用getIEmpDAOInstance()方法而后取得IEmpDAO接口对象，业务层的实现类保存在service.impl子包中
8.定义业务层的工厂类
业务层依然需要被其他的层所使用，所以需要为其定义工厂类，该类也同样被保存在factory子包下，如果从实际的开发来讲，业务层应该分为两种：
* 前台业务逻辑：可以将其保存在service.front包中，工厂类：ServiceFrontFactory
* 后台业务逻辑：可以将其保存在service.back包中，工厂类ServiceBackFactory
9.控制层可以看见Emp、ServiceFactory和IEmpService接口
10.在实际的编写中，子类永远都是不可见的，同时在整个操作里面，控制层完全看不见数据库的任何操作（没有任何的JDBC代码）
11.代码测试
因为最终的业务层是需要由用户去调用的，所以测试分两种
*调用测试：按照传统方式产生对象，而后调用里面的方法进行操作，保存在test子包内，此时客户端的调用非常简单，就是调用业务层方法，不需要涉及到具体的数据存储细节
12.利用Junit进行测试
对于这种业务的测试，使用Junit是最好的选择
首先要选择测试的类或者接口，现在选择好IEmpService接口进行测试
13.实现部门操作
要求使用部门表实现如下功能：【业务层】
* 进行部门数据的添加
*【数据层】要判断要增加的部门编号是否存在，如果不存在则可以添加
【数据层】实现部门数据的保存
* 进行部门数据的修改
*【数据层】进行部门数据的修改
* 进行部门数据的删除
*【数据层】进行部门数据删除
* 进行部门数据的全部查询
*【数据层】进行全部查询
* 可以根据部门编号查询一个部门完整信息
*【数据层】根据编号查询
& 依然要定义Dept.java类
& 定义IDeptDAO接口
几乎所有的数据表受应该具备有基础的CRUD功能（增加，修改，删除数据，根据id查询，查询全部，分页显示，数据统计），那么这些功能的方法每个接口都要重复定义
在整个DAO接口定义的过程之中，不同的表区别在于：VO类、主键类型。那么为了解决重复问题，使用泛型实现接口的继承操作
& 定义DeptDAOImpl子类
&修改DAOFactory类，增加新的接口对象取得方法
&开发IDeptService接口
&实现IDeptServiceImpl子类
&修改业务层工厂ServiceFactory
在使用之前还是需要进行一些测试
14.处理关系
已经实现了雇员和部门的基础操作，但是在雇员里面存在有mgr和deptno两个关联字段
* 修改VO类的定义
修改Emp.java类：添加Emp mgr和Dept dept并添加get和set方法
修改Dept.java类：
* 修改EmpDAOImpl子类
* 增加数据时，需要考虑到雇员的领导以及部门编号
* 修改数据时，也需要发生变化
* 在查询单个雇员信息的时候也需要进行全部内容的查询，也就是说现在的查询里面需要定义新的功能，目的是为了与单表查询区分开
如果要想很好的完成所有的开发要求，前提：单表操作必须非常熟练