Çözüldü Java Optional ile Modeli ne zaman kullanmak gerekir?

706111 · 11 Aralık 2024

Arkadaşlar merhaba.

Diyelimki AccountRepository'si var. Altına da sorguları ekliyoruz böyle. Belki hata verir böyle aynı isimde yazarsak, ona bir şey diyemem şimdilik. (Yani alttaki gibi repostiroy'e tanımlarsak, Spring ya da JPA özel sorgulara dönüştürüyor);

Java:

public interface AccountRepository extends JpaRepository<Account, Long>{
    Optional<Account> findByEmail(String email);
    Account findByEmail(String email);
}

Bunların hangisini hangi amaç ile ve ne zaman kullanmalıyız? İkisi de sonunda bir Account döndürebiliyor.

706111 · 11 Aralık 2024

bitwise dedi:
Biraz code review gibi olacak ama bence soyle olsa daha dogru:

1. DB tanimlarken email ve username alanlarini "unique" index ve muhtemelen not nullable yaparsan
2. Email ve username kullaniliyor mu diye kontrol etmeden direkt insert edersen
3. Kullanilmasi durumunda gelen exception'i handle ederken "Constraint hede hodo failed" olmasindan bunu anlarsin. Boylece her basarili kayit icin 3 yerine 1 defa DB ye istek atmis olursun. Birak o validasyonu RDBMS yapsin senin icin insert ederken.

Ayrica JPA da "existsByX" template'i var. Butun User alanlarini doldurmasindansa sadece bununla eslesen kayit var mi yok mu bana getir seklinde kullanabilirsin. Optional kullanmana da gerek kalmaz, ya true ya da false donecek zira.

Hocam o zaman User böyle mi olmalıdır?

Java:

public class User {   
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id;
    private String firstname;
    private String lastname;
    @Column(unique = true) private String username;
    private String password;
    @Column(unique = true) private String email;
    private boolean enabled;
   
   
    public User() {
        this.enabled = false;
    }
   
}

Hocam birde @Notnull annotasyonunu DTO'da kullanmıştım. Onu User'e de eklemem gerekir mi?

Java:

public class CreateUser{

    private String firstname;
    private String lastname;
    @NotNull private String username;
    @NotNull @NotBlank private String password;
    @NotNull @NotBlank private String repassword ;
   
    @NotNull @NotBlank private String email;

}

bitwise · 11 Aralık 2024

tensa_zangetsu dedi:

Hocam o zaman User böyle mi olmalıdır?

Java:

public class User {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id;
    private String firstname;
    private String lastname;
    @Column(unique = true) private String username;
    private String password;
    @Column(unique = true) private String email;
    private boolean enabled;
 
 
    public User() {
        this.enabled = false;
    }
 
}

Hocam birde @Notnull annotasyonunu DTO'da kullanmıştım. Onu User'e de eklemem gerekir mi?

Java:

public class CreateUser{

    private String firstname;
    private String lastname;
    @NotNull private String username;
    @NotNull @NotBlank private String password;
    @NotNull @NotBlank private String repassword ;
 
    @NotNull @NotBlank private String email;

}

User'a @NotNull eklemene gerek yok, cunku o runtime validasyon annotasyonu. CreateUser 'da kontrol edilmesi yeterli. Ayrica @NotBlank zaten null kontrolu yapiyor, ikisine ayni anda gerek yok.

User'da this.enabled=false yapilan kisim da database de yapilabilir "default false" seklinde. Ama bu haliyle de bence anlasilir. JPA zaten varsa kendi default constructor'i kullaniyor.

Su haliyle insert ederken yapilacak exception handling de eklenirse bence gayet iyi.
Buradaki "catch" blogu ayri bir fonksiyon olabilir. Cok muhtemelen kullanici kendi hesabini update ederken de ayni seyi yapman gerekecek. ( Yeni email adresi kullanimda mi vs )

Java:

try{
repo.save(user)
}catch(Exception e){
    if (e instance of ConstraintViolationException){ // farkli bir err olabilir, hatirlamiyorum tam class'i
      final String errMsg = e.getMessage();
      if(errMsg.contains("username"))    {
          throw new UsernameInUseException(user.userName);
      }else if(errMsg.contains("email")){
          // email in use
      }else{
          throw new InternalError(e);
      }
    }
}

706111 · 11 Aralık 2024

bitwise dedi:
User'a @NotNull eklemene gerek yok, cunku o runtime validasyon annotasyonu. CreateUser 'da kontrol edilmesi yeterli. Ayrica @NotBlank zaten null kontrolu yapiyor, ikisine ayni anda gerek yok.

User'da this.enabled=false yapilan kisim da database de yapilabilir "default false" seklinde. Ama bu haliyle de bence anlasilir. JPA zaten varsa kendi default constructor'i kullaniyor.

Su haliyle insert ederken yapilacak exception handling de eklenirse bence gayet iyi.
Buradaki "catch" blogu ayri bir fonksiyon olabilir. Cok muhtemelen kullanici kendi hesabini update ederken de ayni seyi yapman gerekecek. ( Yeni email adresi kullanimda mi vs )

Java:

try{ repo.save(user) }catch(Exception e){ if (e instance of ConstraintViolationException){ // farkli bir err olabilir, hatirlamiyorum tam class'i final String errMsg = e.getMessage(); if(errMsg.contains("username")) { throw new UsernameInUseException(user.userName); }else if(errMsg.contains("email")){ // email in use }else{ throw new InternalError(e); } } }

Hocam çok teşekkür ettim.

@bitwise hocam peki neden final anahtarı ile bir String oluşturduk?
final String errMsg = e.getMessage();
e.getMessage(); o an zaten değiştirilemez bir mesaj değil midir?

Rahatsız ettim kusura bakmayın.

bitwise · 13 Aralık 2024

tensa_zangetsu dedi:
Hocam çok teşekkür ettim.

@bitwise hocam peki neden final anahtarı ile bir String oluşturduk?
final String errMsg = e.getMessage();
e.getMessage(); o an zaten değiştirilemez bir mesaj değil midir?

Rahatsız ettim kusura bakmayın.

O benim el aliskanligimdan dolayi aslinda, oteki turlu yapsak da olurdu.

Zaten simdi bakinca catch blogunu "Exception e" yerine direkt yakalamak istedigimiz Exception ile olustursak daha mantikli olurmus diye de dusundum.

706111 · 13 Aralık 2024

bitwise dedi:
O benim el aliskanligimdan dolayi aslinda, oteki turlu yapsak da olurdu.

Zaten simdi bakinca catch blogunu "Exception e" yerine direkt yakalamak istedigimiz Exception ile olustursak daha mantikli olurmus diye de dusundum.

Hocam çok teşekkür ettim. Sayenizde daha güzel hazırladım.

bitwise dedi:
Zaten simdi bakinca catch blogunu "Exception e" yerine direkt yakalamak istedigimiz Exception ile olustursak daha mantikli olurmus diye de dusundum.

Yok aslında bu türlü daha iyi. Başka hatalar ile kıyaslayıp, başka hataları da yakalamak için kullanılır yani.

bitwise · 13 Aralık 2024

tensa_zangetsu dedi:
Hocam çok teşekkür ettim. Sayenizde daha güzel hazırladım.

Yok aslında bu türlü daha iyi. Başka hatalar ile kıyaslayıp, başka hataları da yakalamak için kullanılır yani.

Rica ederim. Bu arada ben "ConstraintViolationError" hatasini uydurdum, gercekte atilan exception nedir gelistirme bitince bana yazabilir misin? Onu da merak ediyorum.

706111 · 13 Aralık 2024

bitwise dedi:
Rica ederim. Bu arada ben "ConstraintViolationError" hatasini uydurdum, gercekte atilan exception nedir gelistirme bitince bana yazabilir misin? Onu da merak ediyorum.

DataIntegrityViolationException adli bir exception.

Çözüldü Java Optional ile Modeli ne zaman kullanmak gerekir?

Ayrıntılı düzenleme

706111

Hectopat

bitwise

706111

Hectopat

bitwise

Gigapat

706111

Hectopat

bitwise

Gigapat

706111

Hectopat

bitwise

Gigapat

706111

Hectopat

Benzer konular

Technopat Haberler

Yeni konular

Yeni mesajlar

Gizliliğinize önem veriyoruz