开发者学堂课程【DAO 开发实战业务分析: OR-Mapping 设计改进（ORMapping 简介）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/399/detail/5174
OR-Mapping 设计改进（ORMapping 简介）
内容介绍：
一、问题的提出与改良
二、OR-Mapping 设计思想
一、问题的提出与改良
现在已经完整地实现了 DAO 的程序结构，但是在这些结构之中，虽然每一层次都已经得到了设计的改良，可是还有一个类存在有大量的重复代码,即为MessageDAOImpl 子类。
如果假设现在项目里面有200张数据表存在的话，那么对于 DAO 的实现而言太过于繁琐，因为所有的 PreparedStatement 设置数据部分需要独立完成，而所有的ResultSet 的结果集转为 VO 类型的操作也要独立完成。
而关键性的设计问题在于大量的 PreparedStatement 设置以及 ResultSet 结果处理过程，
如下：
this.pstmt = this.conn. preparedStatement(sql) ;
this.pstmt.setString(1, vo.getName()) ；
this.pstmt.setInt（2，vo.getAge()）;
this.pstmt.setString(3, vo.getPhone()) ；
this.pstmt.setDate(4,new java.sql.Date.(vo.getBirthday().getTime())) ;
this.pstmt.setString(5, vo.getNote()) ；
this.pstmt.setString(6, vo.getMid()) ；
vo = new Member() ;
vo.setMid(rs.getString(1)) ;
vo.setName(rs.getString(2)) ;
vo.setAge(rs.getInt(3)) ;
vo.setPhone(rs.getString(4)) ;
vo.setBirthday(rs.getDate(5)) ;
vo.setNote(rs.getString(6)) ;
那么既然要消除这样的代码，就必须有一个更好的设计思路，对于增加、修改、删除而言，其基本的形式是固定的。
增加操作大部分都是增加完整数据，修改操作可能有些字段修改而有些不进行修改，所以增加和修改的形式基本上固定，所以应该用一些抽象的方式再将这些功能抽象出来以便于重复调用。
那么自然可以想到应该使用一个抽象类。
再看数据层改良，在正常情况下，当有了一个接口之后，从下方之间向上的一定是子接口，那么在子接口之下还应有一个抽象位存在，称为 AbstractDAOImpl 。
而当有100个 DAO 的接口子位，Prepared、Connection 等属性操作一定会在所有子位定义，所以既然会在所有的子位定义，那么没有必要再进行重复定义，如果被定义在抽象类中，用 prepared 权限来定义比较合适。
此处应该用# conn：
Connection 以及再跟上# pstmt：PreparedStatement 这两个属性来完成。
在此基础上，每一个具体的子位在抽象类的基础上都可以编写大量的子位，抽象类可以为子类提供支持，例如重复的 Impl 过程应该由抽象位提供。
而重用设计的关键为不能直接实例化、必须被继承，与子类共享非私有操作以及可以编写一些所有子类的公共实现方法。
所图：
二、OR-Mapping 设计思想
（1）OR-Mapping 的基本设计思路
因为传统的 JDBC 提供有相应的操作支持，但是所有的数据库的操作功能都过于琐碎，这就导致了开发者不得不去面对大量重复又枯燥的代码，但不可否认，JDBC的操作实际上提供的就是利用对象实现了数据库的操作，所以JDBC从传统意义上来讲就属于一个传统的“OR-Mapping”（对象与关系映射，即可以使用对象直接进行数据库的操作）设计思想，那么下面如果要想将 JDBC 的功能支持更大一些，就必须在 JDBC 的基础上进行进一步的开发操作，以实现代码的可重用设计。所以本次主要讲解单表的优化处理操作。
（2）OR-Mapping 的设计实现
JDBC,Hiberante,JDO,MyBatis,IBatis,JPA,Entity Bean 的实现开发框架。
（3）OR-Mapping 的本质
对传统 JDBC 的保障，让用户使用更加方便。
