Çözüldü Generic repository nedir?

dustin poirier · 4 Ağustos 2025

Arkadaşalr generic repository nedir? Ne işe yarar ve en üst seviyede bunu yazmak için nerede kullanılır? Repsoitory patternden farkı nedir? Çok zor mudur? @bitwise abi cevaplarsan sevinirim.

pottie4r · 5 Ağustos 2025

@bitwise Hocam repository pattern'in bazi durumlarda anti-pattern oldugu ve gereksiz soyutlamalar ile performans dusurdugu soyleniyor. Buna nasil karar veriyoruz peki? Bu soyutlamalar ciddi anlamda bir performans kaybina sebep olur mu?

bitwise · 5 Ağustos 2025

pottie4r dedi:
@bitwise Hocam repository pattern'in bazi durumlarda anti-pattern oldugu ve gereksiz soyutlamalar ile performans dusurdugu soyleniyor. Buna nasil karar veriyoruz peki? Bu soyutlamalar ciddi anlamda bir performans kaybina sebep olur mu?

Ben performans sorunu olusturacagini hic dusunmuyorum. Zaten DB operasyonlari bir uygulamanin genel performansini direkt belirleyen zincirin en "zayif" halkasi. Uygulama katmaninda bu tarz abstraction'lar yapmanin performansa anlamli zarar vermesi cok zor.

Elbette burada istisnai durumlar var, ornegin DB'den kastettigimiz Redis ya da Dynamo gibi zaten 10ms altinda std. operasyon yapan bir DB ise bu tarz abstraction'a ihtiyac yok. Zaten her her objeyi bu DB'lere yazmayiz. Veya bazi ORM library'leri bazi query'leri cok suboptimal yazarlar, direkt ORM kullanmamak istenebilir.

Yine de anti-pattern oldugu durumlar var:

- Ornegin her data objesi icin standart CRUD, pagination, sorting, findByX query disinda islemler yapilmasi gerekiyorsa repository pattern'i anlamsiz yere araya yerlestiriyoruz. Ornegin soyle kullanimlar goruyorum bazen:

Java:

@Repository
class UserDAO {
    private UserRepository userRepo; // spring repository pattern
    private EntityManager entityManager; // JPA entity manager
   
    public complexOperasyon(){
        entityManager.hedeHodo() // kompleks isler icin entity
    }
   
    public complex2(){
        // HQL ile query
        return entityManager
        .createQuery("FROM User u WHERE u.name = :name", User.class)
    }
   
    // Native DB layer query
    @Query("select bilmem ne", native=true)
    public findAggregateSortBilmemne(){
        //
    }
   
}

Adamlara standard repository pattern yetmemis, onu kapsayacak yeni bir class olusturmak zorunda kalmislar. O da yetmemis, entityManager ile session ve transaction yonetimi yapmak durumunda kalmislar. HQL yetmemis Query ile native query yazmak zorunda kalmislar.

Repositorynin kendisini baska bir repository component i wrap etmek zorunda kaliyorsaniz o halde zaten repository pattern e ihtiyac yok demektir.

- Bir baska anti pattern oldugu durum da AOP ile transaction yonetmek durumunda kalindigi zaman.

Yani sizin yapacaginiz DB operasyonu specifik bir transaction icinde olacaktir, bunu da okunabilir olmasi icin repository cagrisina yakin konumlandirirsiniz. Bu da repository isteklerinin atomik hale gelmesine ve dolayisiyla performansa ve hatta bug'lara yol acar. Cunku repository pattern tasarim olarak transaction management gorevini soyutlar, kodda gorunmez. Buna da ornek:

Java:

interface UserRepo extends JpaRepository<User, ID>

@Transactional(readonly = false, isolation = Serializable,
              propagation = Requires.NEW)
public void saveUser(){
    // User save islemi yeni bir transaction ve yuksek serializable
    // kullanimi gerektirir. Uygulama bu konuda hassas.
    // dolayisiyla repo.save islemi transaction yoneten save icine alinmis.  
    userRepo.save();
}

Bu yapi da zaten transaction iceren baska bir operasyon'dan saveUser cagirisi yapildiginda transaction icinde transaction icinde transaction gibi sacmaliklara sebep olabiliyor. Bunlarla karsilastim ve debug etmesi inanilmaz kulfetli islemler. Ayrica sadece yuk altinda sacmaladigini gozlemliyorsunuz bazen.

Uzun bir mesaj oldu ama ben aslinda genel olarak OOP'nin bu problemi karisik hale getirdigini dusunuyorum. Functional sekilde transaction pass etmek cok daha okunabilir, takip edilebilir, abstract hale getirilebilinir.

Ornek GO: ( Technopat'a GO ve Kotlin destegi gelsin lutfen )

Kod:

func WithCtx(f func(*sql.Tx) (any, error)) (any, error) {
  tx, err := db.BeginTx()
  defer rollBack // roll back defer hemen
  if err != nil // err handle et
  data, err = f(tx) // op
  commit
  return data, nil // sonuc
}

Bu sekilde acik sekilde Tx management yapan fonksiyonlar ve buna bagli Clojure tanimlari ile cok daha net kod takip edilebilip basitlestirilebiliyor. OOP'nin AbstractTransactionManagerFactoryBean gibi absurdlesen kullanimlarina ihtiyac kalmiyor.

Çözüldü Generic repository nedir?

Ayrıntılı düzenleme

dustin poirier

Kilopat

bitwise

pottie4r

Megapat

bitwise

Gigapat

Benzer konular

Technopat Haberler

Yeni konular

Yeni mesajlar

Gizliliğinize önem veriyoruz