我有一个使用Hibernate 4.x的应用程序，它目前正在使用本机Hibernate API（意味着我有SessionFactory和Session s。我只是noticed不推荐使用现有的Criteria API，而选择JPA的（优质）Criteria API：
Hibernate提供较旧的遗留
org.hibernate.CriteriaAPI，应该被视为已弃用。没有功能开发将针对这些API。最终，特定于Hibernate的标准功能将被移植为JPAjavax.persistence.criteria.CriteriaQuery的扩展。
我不想将我的应用程序转换为直接使用EntityManager（即使从那里很容易获得Hibernate Session），因为我们有大量的自定义Hibernate配置需要更换的逻辑。尽管如此，我肯定想开始使用JPA Criteria API，因为旧的API已被弃用（如果过去的Hibernate版本有任何迹象，可能会在未来的某个随机点消失），并且它们也提供了更好的类型安全性。
如果我使用SessionFactory / Session，我如何使用新的CriteriaQuery / CriteriaBuilder API？
答案 0 :(得分：2)
我们的项目存在同样的困境。
该项目非常复杂：90％的实体是动态生成的;在Hibernate标准API，重DAO和服务层之上实现了API级别，这是非常广泛使用的;我们的hibernate版本经过多次修补以支持特定功能（例如START WITH / CONNECT BY，ARRAY类型在oracle中等等）; postgresql和oracle同时使用，等等。
新的JPA API对我们非常有用。我们需要能够在Criteria API（而不是HQL）级别使用函数（如NVL/coalesce出于某种性能原因，substring，trim等等。
此外，我们需要Hibernate Envers，它仅适用于＆＃34; EntityManager＆＃34; JPA实施。
根据我们的研究结果，不幸的是，根本无法使用原生Hibernate的JPA Criteria API。 Envers也不能使用。 Hibernate项目不断发展并获得新功能。 迁移到新的hibernate版本对我们来说是非常复杂的任务。我们非常担心迁移后无法使用新版本的许多新功能，并且在这个基本框架中不断发展。
因此，我们会考虑两种可能的方式：使用SQLCriterion自己实现Expression s（使用CriteriaQuery解析列名并转换为SQL）或迁移到＆＃34; EntityManager＆＃34; / CriteriaBuilder。第二种方式看起来不可避免。但是迁移到JPA实现带来了许多隐藏的问题，这些问题破坏了我们的项目。
如果我们选择迁移并且它会很有用，我将在这里留下我们将在此活动中遇到的问题。