Repository Pattern Yaklaşımı Yerine Command/Query Object Pattern Yaklaşımı

Bunlar da hoşunuza gidebilir...

8 Cevaplar

  1. İrfan Evrens dedi ki:

    Merhaba,

    Yazı için teşekkürler. Büyük sistemler için ideal görünüyor. Uzun vadeli işlerde dosya sayısının çokluğundan ziyade o dosyaları yönetebilmek de önemli bir konu tabi. Bu anlamda faydalı bir yazı.

    Ben size bir soru sorayım, validasyon kurallarını controller içinde mi çalıştırıyorsunuz yoksa yazılan command ve query sınıfları içinde mi çalıştırıyorsunuz?

    Son olarak .net’de property incject yok mu, constructer inject’den daha okunaklı oluyor da.

    Kolay gelsin.

    • Gökhan Gökalp Gökhan Gökalp dedi ki:

      Merhaba teşekkür ederim yorumunuz için öncelikle. Validasyon biraz geniş bir kavram açıkcası. Business validasyonları, rule validasyonlar vb. Bu tarz cross-custting işlemler için eğer varsa engine katmanının üzerinde bir manager katmanı orada uygulanabilir veyahut aspect’lerle yönetilebilinir oda olmadı command’lar da da yönetmek gibi bir çok yöntem mevcut. Projenizin structure’ına göre değişir. Property injection tabi ki bulunmakta ve bu konuda okunurluğa göre de davranılmamalıdır. Dışarıya expose etmek istemediğim bir property’i inject etmek pek de uygun olmayacaktır.
      İyi günler dilerim.

  2. Efe ÖZYER dedi ki:

    Hocam merhabalar,
    Çalıştığım şirket LOGO kullandığından dolayı işlerimizde genellikle stored procedure kullanıyoruz.
    Bu konuyla ilgili bir makale yazmanız mümkün mü ?
    Teşekkürler.

    • Gökhan Gökalp Gökhan Gökalp dedi ki:

      Selamlar, öncelikle teşekkür ederim yorumunuz için. SP’ler pek ilgi alanım değil açıkcası code-review’lar haricinde. 🙂

      • Murat dedi ki:

        Merhaba Usta
        Bu konularda takıntılıyım, şuan sorumlu olduğum projemi akıla mantığa en uygun şekilde refactor ediyorum. Projemde klasör isimlerinden hangi classın ne tür bir standart yapıyla dizilimesine kadar kusursuza yakın tasarım desenleri araştırırken gördüm makaleyi. Ben repostory paterni daha kullanışlı buldum açıkcası bu da fena değil ama bu sefer class dosyaları gözümü yoracak. Şuan refactore gitmemdeki en büyük neden DTO kullanmamış olmam. DTO(auto map edecek) ve asenkron destekli bir repository patern kurgulayıp işi ilerletmeyi düşünüyorum. Validasyon, log, hata yönetimi gibi işlemler için postsharp kullanmayı düşünüyorum. Hangi orm kullanıcağıma henüz karar veremedim. Bu ihtiyaçlarımı düşünerek örnek bir proje arıyorum ve yorumlarını bekliyorum.

        • Gökhan Gökalp Gökhan Gökalp dedi ki:

          Merhaba,

          Refactor etmeniz, etmeye takıntılı olmanız çok güzel. 🙂 Açıkcası ben kusursuz bir tasarım diye bir şeye inanmıyorum. Fakat bu noktada Repository ile Command/Query’i karıştırmamak gerek. Burada gözünüzü yoracak class çokluklarından ziyade, buradaki seperation’ın amacına, elinizdeki probleme doğru odaklanmak gerek. Cross-cutting işlemler için ise aspect’ler güzel tercih. Hangi orm demişsiniz birde, EF bir çok derdinizi çözecektir. Bu arada Command/Query’deki diğer bir güzel yön ise, querying işlemlerini (örnek misali) Dapper tarzı micro orm’ler ile yaparken, diğer işlemler için EF nimetlerinden yararlanabilmek gibi işlemler de güzel handle edilebilmektedir. Dediğim gibi, probleme ve seperation’a iyi bakmak, düşünmek gerek. 🙂 Göz yormaktan öte bir olay.

  3. Efe ÖZYER dedi ki:

    Bende şirketi değiştirdim zaten 😀 Bu arada kitabınızı almıştım ancak CD’nizi kaybettim. Konuyla ilgili yapabileceğimiz bir şey var mı ? 🙁

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

*