【发布时间】：2015-03-11 06:33:12
【问题描述】：
我是 JPA、JPQL、Hibernate、Querydsl 的新手，现在我在我的项目中看到了这一点使用 Querydsl 进行查询，我想知道为什么选择了这种方法。因此，您可以确定为什么我的项目中存在确切的原因，但您可以说明为什么以及在什么情况下首选 Querydsl。为什么我们可以使用简单的 JPQL 语句？
【问题讨论】：
-
因为它的 API 比冗长的 JPA 标准更自然？
【发布时间】：2015-03-11 06:33:12
【问题描述】：
- 您可以在 IDE 中使用代码完成
- IDE 重构工具有效（或多或少）
- 类型安全
- （几乎）语法安全
- 编译器在错误类型等的编译时生成错误，而 Hibernate 仅在首次运行时抱怨
- 一致性，可以使用相同的原理查询JPA、MongoDB、Collections...
【讨论】：
-
如果重命名实体类属性，IDE 会在 queryDSL 查询中重命名字段吗？用户可以使用 QueryDSL 进行参数查询吗？
-
必须从实体定义中生成定义 DSL 类的查询。是的，您可以进行参数查询。
-
好的，Q 类是在实体的基础上生成的，但是在 QeryDSL 查询中使用实体属性，如果您更改实体属性，QClass 将发生变化，但是您拥有的属性呢在您的旧 DSL 查询中使用？例如，如果您重命名实体类中的属性字段，它将被更改？ IDE 是否处理此更改？
-
如果没有自动更改，但至少它彻底破坏了构建，您可以快速找到破坏的地方。您可以从blog.mysema.com/2010/10/using-querydsl-in-eclipse.html 找到如何在 Eclipse 上设置项目的说明
-
非常感谢@ikettu。
我想对 QueryDSL 的使用提出反对意见。
我不喜欢使用 QueryDSL，原因如下：
- 您需要经常编译项目以保持
Q类的更新 - 您需要设置 IDE 以将在
target上生成的Q类视为普通类。 - 我已经看到 IDE “迷路”，不再识别
Q类 - 我已经创建了简单的 QueryDSL 语句，这些语句生成了非常奇怪且不可预测的 SQL。
即使对最终用户友好，我还是更喜欢使用 JPQL，因为它更接近生成的 SQL 并且更可预测。
但相比 Criteria，我更喜欢 QueryDSL。
【讨论】：
-
为什么投反对票？
-
上述所有负面因素都是由于缺乏正确设置项目以避免这些错误的知识造成的。我对您的答案投了反对票，因为它与 QuesryDSL 是否正常无关。
-
实际上在第一点有一个有效的参数。我正在搜索，似乎从创建/更改 JPA 实体的项目开始就使用 QueryDSL，生成代码并经常跟踪文件会让人头疼。