1.2.2 MyBatis3及替代技术
传统的Java应用都是采用JDBC来访问数据库的,但传统的JDBC采用的是一种基于SQL的操作方式,这种操作方式与Java语言的面向对象特性不太一致,所以Java EE应用需要一种技术,通过这种技术能让Java以面向对象的方式操作关系数据库。
这种特殊的技术就是ORM(Object Relation Mapping),最早的ORM是EntityEJB( Enterprise JavaBean),EJB就是经典Java EE应用的核心,从EJB1.0到EJB2.x,许多人会觉得EJB非常烦琐,所以导致EJB备受诟病。
在这种背景下, Hibernate框架应运而生。 Hibernate框架是一种开源的、轻量级的ORM框架,它允许将普通的、传统的Java对象(POJO)映射成持久化类,允许应用程序以面向对象的方式来操作POJO,而Hibernate框架则负责将这种操作转换成底层的SQL操作。
大多数情况下(特别是对新项目、新系统的开发而言), Hibernate这样的机制无往不利,大有一统天下的势头。但是,在一些特定的环境下, Hibernate这种一站式的解决方案却未必适合。如:
- 系统的部分或全部数据来自现有数据库,出于安全考虑,只对开发团队提供几条
Select SQL(或存储过程)以获取所需数据,具体的表结构不予公开。 - 开发规范中要求,所有牵涉到业务逻辑部分的数据库操作,必须在数据库层由
存储过程实现(就金融行业而言,工商银行、中国银行、交通银行等商业银行都曾在开发规范中严格指定) - 系统数据处理量巨大,性能要求极为苛刻,这往往意味着我们必须通过经过高度优化的
SQL语句(或存储过程)才能达到系统性能设计指标。
面对这样的需求, Hibernate不再适合,甚至无法使用。此时,直接使用JDBC进行数据库操作实际上也是不错的选择,只是拖沓的数据库访问代码、乏味的字段读取操作令人厌烦,而”半自动化”的My Batis,却正好解决了这个问题。
这里的”半自动化”,是相对Hibernate等提供了全面的数据库封装机制的”全自动化”ORM实现而言的,”全自动”ORM实现了POJO和数据库表之间的映射,以及SQL的自动生成和执行。
而MyBatis的着力点,则在于POJO与SQL之间的映射关系。也就是说,使用MyBatis提供的ORM机制,对业务逻辑实现人员而言,面对的是纯粹的Java对象,这与通过Hibernate实现ORM基本一致,而对于具体的数据操作,Hibernate会自动生成SQL语句,但MyBatis则并不会自动生成SQL语句。具体的SQL需要程序员编写,然后通过映射配置文件,将SQL所需的参数以及返回的结果字段映射到指定的POJO。
相对Hibernate等”全自动”ORM机制而言, MyBatis以SQL开发的工作量和数据库移植性上的让步,为系统设计提供了更大的自由空间。作为对”全自动”ORM实现的种有益补充, MyBatis的存在具有特别的意义。MyBatis是Apache组织提供的一个轻量级持久层框架,是一个支持普通SQL查询、存储过程和高级映射的优秀持久层框架。 MyBatis消除了几乎所有的JDBC代码和参数的手工设置过程以及对结果集的检索封装。 MyBatis可以使用简单的XML或注解来进行配置和原始映射,将接口和Java的POJO映射成数据库中的记录。MyBatis作为持久层框架,其主要思想是将程序中的大量SQL语句剥离出来,配置在配置文件中,实现SQL的灵活配置。这样做的好处是将SQL与程序代码分离,可以在不修改程序代码的情况下,直接在配置文件中修改SQL。
除此之外, Oracle的TopLink、 Apache的OJB都可作为替代方案。但由于种种原因,它们并未得到广泛的市场支持,所以这两个框架的资料、文档相对比较少,选择它们需要一定的勇气和技术功底。
原文链接: 1.2.2 MyBatis3及替代技术