Spring Data JPA DAO classes لکھنے کا boilerplate ہٹا دیتی ہے۔ آپ ایک repository interface کا اعلان کرتے ہیں؛ startup پر Spring ایک proxy implementation generate کرتا ہے جو JPA/Hibernate سے چلتا ہے۔ آپ بنیادی CRUD کے لیے کبھی entityManager.persist(...) نہیں لکھتے۔
{
Long id;
String email;
active;
}
<User, Long> {
Optional<User> ;
List<User> ;
}
Derived queries سادہ criteria کے لیے پڑھنے میں آسان ہیں مگر جیسے جیسے شرائط بڑھتی ہیں لمبائی میں پھٹ جاتی ہیں۔ جب ایسا ہو، تو ایک explicit @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)
Interviewers یہ جانچتے ہیں کہ آیا آپ سمجھتے ہیں کہ interface کے پیچھے کیا generate ہوتا ہے۔ مضبوط اشارے: derived-query keywords جاننا، جب method names بے ڈھنگے ہو جائیں تو @Query چننا، پوری tables load کرنے کے بجائے Pageable استعمال کرنا، اور یہ آگاہی کہ lazy associations N+1 مسئلہ پیدا کر سکتی ہیں — ایک موضوع جسے وہ اکثر اگلے سوال میں دھکیل دیں گے۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں