Konu başlangıcı
Selamlar herkese, iyi forumlar.
Son zamanlarda backend tarafında yeni bir API projesine başlarken hep aynı ikilemde kalıyorum, sizin de tecrübelerinizi/fikirlerinizi merak ettim.
Bildiğiniz gibi piyasada standart bir alışkanlık var; proje açılır açılmaz hemen bir IGenericRepository<T> ve GenericRepository<T> patlatılıyor: Add, Update, Delete, GetById, GetAll... Üstüne bir de Unit of Work katmanı çekiliyor.
Ama iş biraz ilerleyince ve sorgular karmaşıklaşınca durum genelde şuna dönüyor:
EF Core'un DbSet'i zaten kendi içinde bir Repository mantığıyla çalışıyor, DbContext de zaten Unit of Work işini görüyor. Araya bir katman daha koyup aynı metotları tekrar wrap ediyoruz gibi hissettiriyor.
Generic repodan IQueryable dönsek katman ayrımının bir esprisi kalmıyor; dönmeyip List dönelim desek bu sefer Select, Include veya Pagination işleri çorbaya dönüyor. Arkasından GetByIdWithDetailsAsync(...) gibi onlarca saçma metod türemeye başlıyor.
"Test yazarken mock'laması kolay olsun" deniyor ama InMemory DB veya Testcontainers varken sırf bunun için projeyi onlarca interface'e boğmak gerçekten değer mi?
Kısacası küçük-orta ölçekli projeleri geçtim, orta-büyük işlerde bile bazen "temiz mimari kuracağız" derken basit bir CRUD işlemi için 5 dosya gezmekten başka bir şey yapmıyoruz gibi geliyor. CQRS tarafında handler içinde direkt DbContext enjekte edip geçmek bana çok daha pragmatik ve temiz gelmeye başladı.
Siz şirket projelerinizde veya kendi işlerinizde bu yapıyı nasıl kurguluyorsunuz? Hâlâ Generic Repo + Unit of Work devam mı, yoksa daha sade/doğrudan yaklaşımlara mı geçtiniz?
Görüşleri bekliyorum.
Son zamanlarda backend tarafında yeni bir API projesine başlarken hep aynı ikilemde kalıyorum, sizin de tecrübelerinizi/fikirlerinizi merak ettim.
Bildiğiniz gibi piyasada standart bir alışkanlık var; proje açılır açılmaz hemen bir IGenericRepository<T> ve GenericRepository<T> patlatılıyor: Add, Update, Delete, GetById, GetAll... Üstüne bir de Unit of Work katmanı çekiliyor.
Ama iş biraz ilerleyince ve sorgular karmaşıklaşınca durum genelde şuna dönüyor:
EF Core'un DbSet'i zaten kendi içinde bir Repository mantığıyla çalışıyor, DbContext de zaten Unit of Work işini görüyor. Araya bir katman daha koyup aynı metotları tekrar wrap ediyoruz gibi hissettiriyor.
Generic repodan IQueryable dönsek katman ayrımının bir esprisi kalmıyor; dönmeyip List dönelim desek bu sefer Select, Include veya Pagination işleri çorbaya dönüyor. Arkasından GetByIdWithDetailsAsync(...) gibi onlarca saçma metod türemeye başlıyor.
"Test yazarken mock'laması kolay olsun" deniyor ama InMemory DB veya Testcontainers varken sırf bunun için projeyi onlarca interface'e boğmak gerçekten değer mi?
Kısacası küçük-orta ölçekli projeleri geçtim, orta-büyük işlerde bile bazen "temiz mimari kuracağız" derken basit bir CRUD işlemi için 5 dosya gezmekten başka bir şey yapmıyoruz gibi geliyor. CQRS tarafında handler içinde direkt DbContext enjekte edip geçmek bana çok daha pragmatik ve temiz gelmeye başladı.
Siz şirket projelerinizde veya kendi işlerinizde bu yapıyı nasıl kurguluyorsunuz? Hâlâ Generic Repo + Unit of Work devam mı, yoksa daha sade/doğrudan yaklaşımlara mı geçtiniz?
Görüşleri bekliyorum.