Spring Data JPA beseitigt die Boilerplate des Schreibens von DAO-Klassen. Du deklarierst ein Repository-Interface; beim Start generiert Spring eine Proxy-Implementierung, die von JPA/Hibernate gestützt wird. Du schreibst nie entityManager.persist(...) für einfaches CRUD.
{
Long id;
String email;
active;
}
<User, Long> {
Optional<User> ;
List<User> ;
}
Derived Queries sind für einfache Kriterien lesbar, wachsen aber mit zunehmenden Bedingungen explosionsartig in der Länge. Wenn das passiert, wechsle zu einem expliziten @Query:
@Query("SELECT u FROM User u WHERE u.email = :email") // JPQL, not SQL
Optional<User> lookup(@Param("email") String email);
// Native SQL when you need DB-specific features:
@Query(value = "SELECT * FROM users WHERE active = true", nativeQuery = true)
List<User> findActiveNative();
Page<User> findByActiveTrue(Pageable pageable); // pass PageRequest.of(0, 20)
Interviewer prüfen, ob du verstehst, was hinter dem Interface generiert wird. Starke Signale: die Keywords von Derived Queries zu kennen, @Query zu wählen, wenn Methodennamen unhandlich werden, Pageable zu verwenden, statt ganze Tabellen zu laden, und sich bewusst zu sein, dass Lazy-Assoziationen das N+1-Problem auslösen können – ein Thema, in das sie oft als Nächstes drängen.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden