在Spring Repository中使用Querydsl和JPAQuery处理复杂查询是否可行？

第一个问题：将Querydsl复杂查询迁移到Repository的方案完全可行，不存在EntityManager注入障碍 #

Spring Data JPA本身提供了自定义Repository扩展机制，完全支持将复杂查询逻辑收拢到Repository层，具体实现步骤如下：

1. 先定义自定义扩展接口，声明复杂查询的方法签名：

public interface UserRepositoryCustom {
    List<User> findDeletableUsers(Date compareDate, 条件参数1, 条件参数2...);
}

2. 编写该接口的实现类，你可以直接在实现类中注入EntityManager，也可以直接继承Spring提供的QuerydslRepositorySupport简化Querydsl开发，无需手动管理EntityManager：

public class UserRepositoryImpl extends QuerydslRepositorySupport implements UserRepositoryCustom {

    // 也可以直接注入EntityManager，Spring完全支持
    // @PersistenceContext
    // private EntityManager entityManager;

    public UserRepositoryImpl() {
        super(User.class);
    }

    @Override
    public List<User> findDeletableUsers(Date compareDate, 条件参数1, 条件参数2...) {
        // 这里直接写你原来的Querydsl逻辑即可
        JPAQuery<User> query = new JPAQuery<>(entityManager);
        return query
                .select(user)
                .from(user)
                .join(someTable)
                .on(user.id.eq(someTable.user.id))
                .where(user.notIn(createSubquery(compareDate))
                        .and(condition1)
                        .and(condition2)
                        .and(condition3))
                .distinct()
                .fetch();
    }

    private JPQLQuery<User> createSubquery(Date compareDate) {
        return JPAExpressions
                .select(user)
                .from(user)
                .join(someOtherTable)
                .on(user.id.eq(someOtherTable.user.id))
                .where((condition4
                        .and(condition5)
                        .and(condition6)))
                .distinct();
    }
}

3. 让你原有继承JpaRepository的接口同时继承自定义扩展接口即可，Spring会自动匹配实现类，你在Service层就可以直接调用该方法，和调用派生查询用法完全一致：

@Repository
public interface UserRepository extends JpaRepository<User, Long>, UserRepositoryCustom {
    Optional<User> findByEmail(String email);
}

这个方案是Spring Data官方推荐的自定义查询扩展方式，不存在任何注入或者兼容问题。

第二个问题：是否用@Query取决于查询的动态性和复杂度，没有绝对的推荐标准，可以参考以下判断规则： #

• 如果你的复杂查询是无动态条件、逻辑完全固定的，用@Query写JPQL/原生SQL完全没问题，写法更简洁，不需要额外维护自定义实现类。
• 如果你的查询存在动态条件拼接、多维度动态排序、多表嵌套关联/子查询的场景，更推荐用Querydsl实现，优势非常明显：
  • 类型安全：编译期就能校验字段、关联关系的正确性，不会出现运行时才发现SQL字段名写错的问题
  • 可读性远优于冗长的字符串SQL，复杂逻辑拆分、注释都更方便
  • 重构友好：实体类字段改名时IDE会自动同步Querydsl的查询代码，不需要手动修改@Query里的硬编码字符串
  • 动态条件拼接不需要写大量if-else拼SQL字符串，也不需要处理@Query里复杂的coalesce、SPEL表达式兼容多场景的问题

内容的提问来源于stack exchange，提问作者Robert Strauch