1.从传统的JDBC编程开始:
1)JDBC是由SUN公司提出的一系列规范,它制定了接口规范。其具体的实现是由各个数据库厂商去实现的,因为每个数据库都有其特殊性,这些是java规范没有办法确定的,所以说JDBC是一种典型的桥接模式。通过JDBC编程主要有以下几个步骤:
1.1)使用JDBC编程需要连接数据库,注册驱动和数据库信息
1.2)操作Connection,打开Statement对象
1.3)通过Statement执行sql语句,返回结果到ResultSet对象
1.4)使用ResultSet读取数据,然后通过代码转化为具体的POJO对象。
1.5)关闭数据关的相关资源。
传统的JDBC方式存在一些弊端,
第一:代码量相当大,需要先获取连接,然后处理JDBC底层事务,处理数据类型。还需要操作Connection对象、Statement对象和ResultSet对象去拿到数据。
第二:我们要对JDBC编程可能产生的异常进行捕捉处理并正确关闭资源。
所以有了ORM模型,其实ORM是基于JDBC进行封装的。不同的ORM模型对JDBC封装的强度是不一样的。
2.ORM模型
ORM模型就是数据库表和POJO对象映射关系模型
java<------->映射配置<-------->数据库
作为经典的ORM框架Hibernate的优势在于通过配置一个hibernte.cfg.xml来作为数据库的连接信息,然后建立Hibernate的工厂对象SessionFactory,用它来作为全局对象产生Session接口,因为它是作为全局对象的,所以可以到处引用,这样在一个会话中就不用操作多个对象了,只需要操作Session对象即可。在关闭资源的时候也只需要关闭一个Session即可。但是Hibernate也存在这严重的不足,其最致命的问题就是性能问题,Hibernate 屏蔽了SQL,做的全表的映射,但是通常我们在数据传输的过程中我们往往关注的仅仅是几个字段,这样的情况下就会有明显的带宽浪费,就拿我最近处理的一个bug来说,业务场景大致是,在wms系统中我们需要修改容器类型,在修改容器类型的过程中,我们需要查询仓库商品表中的所有商品,对于大型的仓储系统来说商品表中数据是相当庞大的,我们系统中查询的数据量在50w+,但是在查询过后我们仅仅需要使用对象的id字段,如果我们盲目的去查询所有字段返回对象的话,就意味着一次性会产生50w+的对象,直接触发fullGC,当fullGC触发时,所有的程序停止,直接宕机。对于这样的情况,一味的扩大内存肯定是不可取的,因为商品的数量还会持续增长,不可能以为的从硬件上来满足需求。事实上我们实用的仅仅是id字段,我们查询id字段即可,而不是查询所有的字段。这显然是全表映射不能满足的。
同时hibernate对于多表关联和复杂SQL查询支持是很差的,需要自己手写SQL,返回后需要自己根据数据组装POJO。而且不支持存储过程。
3)Mybatis
mybatis的优势在于它是一个半自动的持久层框架,它需要手动的区配POJO、SQL和映射关系,而全表映射的Herbernate只需要提供POJO和映射关系即可。
mybatis提供的持久层框架包括了SQL Maps和DAO。它要求我们不仅需要提供映射文件,还需要我们提供SQL语句。映射文件需要包含:1.SQL 2.映射关系 3.POJO 。动态SQL是mybatis的一大亮点,可以通过配置决定SQL映射规则,同时也可支持存储过程。对于一些复杂的和需要优化性能的SQL的查询的优势也就突出体现了。我们在书写SQL后并不需要给出映射规则,通过SQL列名和POJO的属性名保持一致,Mybatis会自动的提供映射规则。再者,我们需要提供一个接口,而不需要具体的实现类。
Mybatis的核心组件:1.SqlSessionFactoryBuilder(构造器):它会根据配置信息或者代码来生成SqlSessionFactory(工厂接口)
2.SqlSessionFactory:用来生成SqlSession(会话)
3.Sqlsession:是一个既可以发送SQL去执行并返回结果,也可以获取Mapper的接口。
4.SQL Mapper:它是Mybatis新设计出来的组件,它是一个java接口和XML文件(注解也可)构成的,需要给出对应的SQL和映射规则。它负责发送SQL去执行,并返回结果。
以下来逐个介绍Mybatis的各个组件
1:SqlSessionFctory是通过SqlsessionFactoryBuilder来获得的,这里SqlSessionFactory是一个工程接口而不是实现类,它的任务仅仅是创建SqlSession。SqlSession是一个类似于JDBC的Connection的东东。创建工厂方式有两种,一种是用xml配置来实现。而另一种是通过java代码来实现。然而第二种并没有尝试过,通常情况下也是通过第一种来实现的。这样能很好的避免一些硬编码。在mybatis应用的整个生命周期中,会有个org.apache.ibatis.session.Configuration对象,我们将xml文件保存到Configuration中,也就让其存在于内存中,方便我们从这个对象中读取配置文件,性能高,单例占用的空间是极小的,基本不占用存储空间。SqlSession的实现类有DefaultSqlSessionFactory和SqlSessionManager但是目前使用的仅仅是前者。(mybatis要稍微停更一下了,新的工作中版本控制工具换成了git了,先解决眼下的问题,开始认真学习下git)