132 第十三天 魔乐java基础视频学习笔记.docx

132 第十三天 魔乐java基础视频学习笔记.docx

《132 第十三天 魔乐java基础视频学习笔记.docx》由会员分享，可在线阅读，更多相关《132 第十三天 魔乐java基础视频学习笔记.docx（22页珍藏版）》请在冰豆网上搜索。

132第十三天魔乐java基础视频学习笔记

1、课程名称：

DAO设计模式

2、知识点：

2.1、上次课程的主要知识点

1、面向对象；

2、Java类集；

3、JDBC使用PreparedStatement进行数据的CRUD。

2.2、本次预计讲解的知识点

1、熟悉程序分层的概念，以及业务层和数据层的划分；

2、使用DAO设计模式实现单表映射以及泛型应用；

3、使用DAO设计模式实现数据表的关系映射（一对多）。

3、具体内容

之前的所有内容都在本处进行总结，而且对于之前的一些概念不清楚的东西（代码会写）那么都可以不用去看了，把本次程序弄会了，一切就都会了，后面也就都会了。

3.1、程序分层（理解）

在一个完整的项目之中，对程序进行合理的分层，可以让开发变得更加的方便，也更加的具备层次感，每一层有每一层的开发人员，例如：

可以简单的理解为美工+程序相分离。

如果按照含金量来讲，首先把握住业务层是整个程序的实现关键，但是对于前台显示更加的重要。

今天的主要任务是观察业务层和数据层的开发，而到了JavaWEB之后，才开始实现显示层和控制层的开发。

在项目之中后台的简历直接有着重要的地位，但是不同层之间最为重要的连接组成部分就是接口，所以整个代码开发之中，对于后台代码就一定要有两个组成接口（业务层接口，给以后的控制层使用、数据层接口，给以后的业务层使用）。

·数据层（数据访问层，DataAccessObject）：

指的是执行数据的具体操作，而现在的开发之中，大多数都是针对于数据库的开发，所以在数据层之中的主要任务是负责完成数据的CRUD，而在java之中，如果要想进行数据的CRUD实现，肯定使用java.sql.PreparedStatement接口；

·业务层（业务对象，BusinessObject，BO，又或者将其称为Service，服务器），服务器的主要目的是根据业务需求进行数据层的操作。

一个业务层要包含多个数据层的操作。

清楚了基本概念之后，那么新的问题就该出现了，如何去区分业务层或者是数据层？

下面以玉市先生吃饭为例，说明一下。

如果说现在某一个项目业务非常复杂，可能分为若干个子业务，那么久还需要一个总的业务层操作。

3.2、实例分析（重点）

下面以emp数据表（empno、ename、job、hiredate、sal、comm，都是基本字段）为例分析一个操作，客户要求可以实现如下的几个功能：

·【业务层】增加一个新雇员信息；

|-[数据层]：

要根据增加的雇员编号查看此雇员是否存在；

|-[数据层]：

如果雇员不存在则执行插入操作，如果存在则不插入；

·【业务层】修改一个雇员的信息；

|-[数据层]：

直接传入新的数据即可，如果没有修改返回的更新行数是0；

·【业务层】删除一个雇员的信息；

|-[数据层]：

直接传入要删除的雇员编号即可，如果没有此雇员信息返回的是0；

·【业务层】根据编号查询一个雇员的信息；

|-[数据层]：

返回一个雇员的完整信息；

·【业务层】取得全部雇员的信息，要求可以实现模糊查询和分页显示，查询结果除了返回数据之外，还要求知道模糊或全部查询或全部查询是所返回的全部数据量。

|-[数据层]：

模糊或查询全部满足条件的雇员数据，多个数据；

|-[数据层]：

使用COUNT（）进行满足条件的数据统计。

3.3、准备阶段（重点）

3.3.1、VO类：

负责数据的传输与包装

但是现在有一个最为严重的问题出现了，不同层之间（这些层除了数据层要操作SQL之外，那么其它层操作的数据都应该是对象），所以应该有一个负责传输的数据对象，这个对象可以称为ValueObject（VO、POJO、TO、PO）。

但是，现在对于简单Java类的开发原则也发生了一些变化：

·类名称要和表名称保持一致；

·为了日后类的操作方便，所有的简单Java类必须实现java.io.Serializable接口；

·类中不运行出现任何的基本数据类型，只能使用包装类；

·类之中的所有属性都必须封装，必须都编写setter、getter；

·类之中一定要提供无参构造方法。

在DAO的开发之中，所有的名称都有严格规定，假设现在的项目的总包名称为：

cn.mldn.oracle，那么现在这个VO类的保存包名称就应该是cn.mldn.oracle.vo。

范例：

定义cn.mldn.oracle.vo.Emp类

3.3.2、DatabaseConnection类：

负责数据库连接

既然现在要完成数据层的开发，那么久一定需要数据库的连接与关闭操作，可是如果将数据库的连接和关闭都写在每一个数据层之中，这样代码过于重复，而且也不方便维护，那么为了方便起见，现在定义一个DatabaseConnection的类，这个类专门负责取得和关闭数据库连接。

而这个类定义在cn.mldn.oracle.dbc包之中。

范例：

定义cn.mldn.oracle.dbc.DatabaseConnection

如果再实际的工作之中，按照DAO最早提出的标准，对于数据层的实现类还需要实现数据库的移植操作。

即：

对于数据库连接类应该变为一个专门负责连接的接口，就好像以下的形式一样：

而后如果一个项目可能在Oracle或DB2下运行，那么针对于这两种数据库分别定义一个接口实现类，以对应两个不同的数据库连接，但是这种开发已经和现在的模式有些出入了，而且特别的麻烦，所以在本次为了和日后的开发可以更好的联系在一起，只是定义了一个类而已。

3.4、开发数据层（重点）

3.4.1、定义IEmpDAO接口：

数据层开发标准

不同层之间的操作依靠的是接口，所以数据层的开发首先要定义出来的就是标准，那么既然是标准就需要定义的是一个接口，现在很明显针对的是emp表，所以这个接口的名称就应该为“表名称DAO”，即：

EmpDAO，但是这里有一个问题了，接口和类的命名要求是一致的，所以为了从名称上区分出接口或者是类，则建议在接口名称前增加一个字母“I”，表示Interface的含义，即emp这张实体表的操作标准的接口名称为IEmpDAO，而且这个接口应该保存在cn.mldn.oracle.dao包之中。

那么对于这个接口的开发主要是针对于数据的两种操作（更新、查询），所以从开发标准上对于命名也有着严格的要求，而且必须遵守。

基本标准如下：

·更新操作：

以“doXxx（）”的方式命名，例如：

doCreate（）、doUpdate（）、doRemove（）；

·查询操作，因为查询操作分为两类：

|-数据查询：

以“findXxx（）”或“findByXxx（）”为主，例如：

findAll（）、findByld（）、findByJob（）；

|-统计查询：

以“getXxx（）”或“getByXxx（）”为主，例如：

getAllCount（）、getByJobCount（）。

范例：

编写IEmpDAO接口的操作标准

现在开发的标准只是满足于程序需求的提出需要。

3.4.2、定义IEmpDAO接口的实现类

既然在接口中已经定义了数据层的操作标准，那么对于实现类只需要遵循数据层的CRUD操作即可，但是对于DAO接口的实现类需要有明确的定义，要求将其定义在：

cn.mldn.oracle.dao.impl包之中；

范例：

定义EmpDAOImpl子类

·现在有如下一种的子类实现接口方式：

如果真的按照这种方式实现的程序，有两个重要问题：

·对于数据层之中给出的若干方法，由服务层调用，一个服务层要执行N个数据层，那么每次执行的时候开一次关闭一次数据库？

·按照异常的处理机制，如果现在执行的过程之中出现了错误，那么顺着throws就结束调用了，数据库就再也无法关闭了。

按照之前的分析，一个业务要进行多个数据层操作，所以数据库连接与关闭交给业务层做最合适，而数据层只需要有一个Connection对象就可以操作了，它不需要关系这个对象是从哪里来的，怎么来的，只关心能不能使用。

3.4.3、定义DAO工厂类

由于不同层之间只能依靠接口取得对象，所以就一定需要定义工厂操作类，工厂类定义在cn.mldn.oracle.factory包之中，名称为DAOFactory。

范例：

定义工厂类

3.5、开发业务层（重点）

3.5.1、开发业务层标准

业务层以后也是需要留给其它层进行调用的，所以业务层定义的时候也需要首先定义出操作标准，而这个标准也依然使用接口完成，对于业务层，接口命名要求：

表名称+Service，例如：

IEmpService，表示操作Emp表的业务。

范例：

在cn.mldn.oracle.service包中定义IEmpService

3.5.2、定义业务层标准的实现类

如果现在要想实现业务层的标准，必须有一个原则先把握住：

一个业务层的方法操作要调用多个数据层，同时每个业务要处理数据库的打开和关闭。

范例：

定义标准实现类——cn.mldn.oracle.service.impl.EmpServiceImpl

3.5.3、定义Service工厂类

如果要取得IEmpService接口对象，一定也需要使用工厂类，避免耦合问题。

范例：

定义cn.mldn.oracle.factory.ServiceFactory类

3.6、定义测试类

一切的程序完成之后，下面就需要编写测试程序，对于测试程序现在有两种方法完成：

·方式一：

可以直接编写主方法，自己根据他的返回值结果进行判断是否成功；

·方式二：

利用JUNIT完成，这样的做法标准，而且也方便日后调试。

如果要使用JUINT则就需要建立一个个的TestCase（测试用例），而且现在再进行测试的时候，应该首先选择的是服务层接口，因为选择不是针对于接口测试，而是针对于方法测试，方法就可以不用自己去编写了。

范例：

编写测试程序

3.7、完成dept操作

完成了Emp操作之后，下面继续完成dept表的操作，那么对dept的操作现在有如下额要求：

·【业务层】增加一个新部门；

|-【数据层】判断增加的部门编号是否存在

|-【数据层】增加部门数据；

·【业务层】修改一个部门信息；

|-【数据层】调用修改操作；

·【业务层】删除一个部门信息；

|-【数据层】调用删除操作；

·【业务层】根据部门编号取得一个部门的信息；

|-【数据层】调用根据id查询的操作；

·【业务层】查询全部的部门信息；

|-【数据层】查询全部

1、开发DatabaseConnection.java类，已经开发完成；

2、开发Dept的vo类：

3、开发IDeptDAO接口

这个时候所编写的接口，第一反应发现除了参数不一样之外，和IEmpDAO一样，而且就算现在有几百张表，对于一些基本操作：

插入数据、更新全部、删除数据、根据ID查询数据、查询全部数据、带分页查询、统计分页的数据量。

没有必要重复编写，各个表不同的只有两块：

VO类、ID类型。

所以现在对于接口就必须重新设计了。

范例：

定义一个公共的IDAO接口

而每一张数据表，除了以上的基本功能之外，还会包括一些自己的独特功能，所以可以在子接口中完成。

范例：

定义IDeptDAO接口

4、开发DAO接口的实现类：

5、在DAOFactory类之中，增加新的方法，取得IDeptDAO接口实现类对象；

6、开发服务层接口

7、开发服务层接口实现类

8、在ServiceFactory接口之中增加新的方法，可以取得IDeptService接口对象；

3.8、使用mgr字段操作

在emp表中的mgr字段，表示的是每一个雇员的领导，如果现在要想加上这种关系，需要做如下的几步。

1、在Emp类之中表示出领导的关系，增加一个mgr属性；

2、修改DAO实现类，因为现在操作数据的时候要考虑mgr字段了。

3.9、使用deptno字段操作

Emp表中的deptno字段是一个每一个雇员所属的部门编号，所以在这之中就会发生如下的两类关系：

·关系一：

一个雇员属于一个部门；

·关系二：

一个部门有多个雇员。

范例：

首先在Emp类之中增加一个Dept的操作。

2、修改EmpDAOImplements的实现子类上。

4、总结

1、程序的分层操作一定要掌握；

2、基本操作，要求对于单表的CRUD灵活编写，半小时写完一个；

3、对于表之间的关系，必须会。