持久层框架大火情况下，传统的JDBC链接数据库进行操作的诸多弊端也让越来越多开发者逐渐抛弃它，这些写法还是我在学校做实验项目时候的写法，但是不管怎样，对它做个总结，给自己青春一个交代哈哈哈哈。
记得当时是Struts2框架，专门定义了一个Java类是JdbcConnectionUtil什么什么的，反正那个类就是一个工具类，里面就有一个什么sqlQuery( String queryStirng )方法什么的，哪里都可以用它，接收一段SQL语句，执行完之后返回一个结果集合。
package com.company;
import java.sql.*;
public class JdbcConnection {
public ResultSet sqlQuery(String query ) throws ClassNotFoundException, SQLException {
// 创建专门用于连接的Connection
Connection connection = null;
// 创建预编译的statement,主要用于向数据库发送参数和SQL语句。
// 预编译的statement传的SQL语句回报存在数据库缓存中，下一次相同的SQL进来不会再在服务层进行编译优化
PreparedStatement preparedStatement = null;
// 由于这里是展示方法，不会有query传进来，所以我自己写一句SQL
String sql = "select * from Customer c where c.id = ?";
// 定义接受的结果集
ResultSet resultSet = null;
// 加载驱动，也就是引入那个mysql连接的jar包，并且填的是它的全限定名才能用Class.forName这种反射的方式加载进来
Class.forName("com.mysql.jdbc.driver");
// 通过驱动类获取数据库连接
DriverManager.getConnection("自己的数据库IP：数据库端口号/库名","连接的用户名","连接的密码");
// 放入自己写的SQL
preparedStatement = connection.prepareStatement(sql);
// 穿进去参数给指定下标位置的占位符,1代表？占位符的下标，3就是c.id = 3
preparedStatement.setInt(1,3);
// 获取到结果集
resultSet = preparedStatement.executeQuery();
// 按照生命时候的反向顺序关闭连接释放资源
resultSet.close();
preparedStatement.close();
connection.close();
return resultSet;
}
}
我做Struts2使用的时候，并不觉得有什么问题（也是因为自己太蠢）；后来实际项目开发了，才发现这种原生态方式，真的是苦不堪言。
（1）所有的SQL语句都是一次性负责一个业务的，完全写死，没有通用型。参数的个数，位置，请求参数类型，返回值类型也都是写死的。100个接口需求就要写100条SQL，有的可能大体上一样但是参数变动一点点的都要写多一条。
mybatis 的解决方案：提供了XML式SQL，IOC容器根据对应的service找到持久层的增强型接口（专门负责与数据库交互的），再读取拼装SQL碎片化来最大程度的复用SQL语句。通过resultType规定类型。
（2）频繁地创建和释放链接，对数据库链接资源造成很大的浪费，严重影响性能。一个线程过来一次创建一次马上销毁一次，这个成本是很大的。
mybatis提供了链接池，固定链接数保持链接，线程过来就给一条链接，线程用完了就把链接放回池中，而不是频繁地创建销毁。
（3）冗余代码会非常多，很难根据业务模块区分对应的数据库操作类。
mybatis中就是让Spring的service调用到相对应的持久层interface，同时允许在接口上@Select（“”）等注解方式写SQL。
（4）可以看到返回类型都是ResultMap；回到对应的方法还要自己再进行解析。也就是返回的结果集类型是写死的。
mybatis中使用了规定返回值类型，可以是简单的int , string ，也可以是pojo的Users，Customer等，我们不需要自己再解析，只需要用到对应类型去接收就行。