这里我写了三种不同的查询方法，对于比较简单的查询，可以通过OID的方式进行，也就是testORM方法中对应的代码。这种方式不需要写 SQL，完全由 Hibernate 去生成。生成的 SQL 如下：
select article0_.id as id1_0_0_, article0_.title as title2_0_0_, article0_.author as author3_0_0_, article0_.content as content4_0_0_, article0_.create_time as create_t5_0_0_ from article article0_ where article0_.id=?第二种方式是通过HQL进行查询，查询过程对应测试类中的testHQL方法。这种方式需要写一点 HQL，并为其设置相应的参数。最终生成的 SQL 如下：
select article0_.id as id1_0_, article0_.title as title2_0_, article0_.author as author3_0_, article0_.content as content4_0_, article0_.create_time as create_t5_0_ from article article0_ where article0_.author=? and create_time>?第三种方式是通过 JPA Criteria 进行查询，JPA Criteria 具有类型安全、面向对象和语义化的特点。使用 JPA Criteria，我们可以用写 Java 代码的方式进行数据库操作，无需手写 SQL。第二种方式和第三种方式进行的是同样的查询，所以生成的 SQL 区别不大，这里就不贴出来了。
下面看一下测试代码的运行结果：
在 Java 中，就持久层框架来说，MyBatis 和 Hibernate 都是很热门的框架。关于这两个框架孰好孰坏，在网上也有很广泛的讨论。不过就像我前面说到那样，技术之间通常没有高低之分，适不适合才是应该关注的点。这两个框架之前的区别是比较大的，下面我们来聊聊。
从映射关系上来说，Hibernate 是把实体类（POJO）和表进行了关联，是一种完整的 ORM (O/R mapping) 框架。而MyBatis 则是将数据访问接口（Dao）与 SQL 进行了关联，本质上算是一种 SQL 映射。从使用的角度来说，使用 Hibernate 通常不需要写 SQL，让框架自己生成就可以了。但 MyBatis 则不行，再简单的数据库访问操作都需要有与之对应的 SQL。另一方面，由于 Hibernate 可自动生成 SQL，所以进行数据库移植时，代价要小一点。而由于使用 MyBatis 需要手写 SQL，不同的数据库在 SQL 上存在着一定的差异。这就导致进行数据库移植时，可能需要更改 SQL 的情况。不过好在移植数据库的情况很少见，可以忽略。
上面我从两个维度对 Hibernate 和 MyBatis 进行了对比，但目前也只是说了他们的一些不同点。下面我们来分析一下这两个框架的适用场景。
Hibernate 可自动生成 SQL，降低使用成本。但同时也要意识到，这样做也是有代价的，会损失灵活性。比如，如果我们需要手动优化 SQL，我们很难改变 Hibernate 生成的 SQL。因此对于 Hibernate 来说，它适用于一些需求比较稳定，变化比较小的项目，譬如 OA、CRM 等。