Spring Data JPA elimina el boilerplate de escribir clases DAO. Declaras una interfaz de repositorio; en el arranque Spring genera una implementación proxy respaldada por JPA/Hibernate. Nunca escribes entityManager.persist(...) para el CRUD básico.
{
Long id;
String email;
active;
}
<User, Long> {
Optional<User> ;
List<User> ;
}
Las derived queries son legibles para criterios simples, pero se disparan en longitud a medida que crecen las condiciones. Cuando eso ocurre, baja a un @Query explícito:
@Query("SELECT u FROM User u WHERE u.email = :email") // JPQL, no SQL
Optional<User> lookup(@Param("email") String email);
// SQL nativo cuando necesitas funcionalidades específicas de la BD:
@Query(value = "SELECT * FROM users WHERE active = true", nativeQuery = true)
List<User> findActiveNative();
Page<User> findByActiveTrue(Pageable pageable); // pasa PageRequest.of(0, 20)
Los entrevistadores indagan si entiendes lo que se genera detrás de la interfaz. Señales fuertes: conocer las keywords de las derived queries, elegir @Query cuando los nombres de método se vuelven inmanejables, usar Pageable en lugar de cargar tablas enteras, y ser consciente de que las asociaciones lazy pueden disparar el problema N+1, un tema hacia el que a menudo empujarán a continuación.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar