C# event sözleşmeleri: payload, bildirim ve karar tasarımı
C# dilinde event yalnızca bir delegate imzası tanımlar; olayın neyi anlattığını, ne zaman tetiklendiğini ve abone yokken ne olacağını söylemez. Nick Cosentino, geçmiş zamanlı bir gerçeği duyuran notification ile gelecek zamanlı bir soru soran karar event'ini ayırıyor ve sabit payload, tek sahipli karar callback'i ile dürüst hata sınırları öneriyor.
Kilit noktalar
- Event isimleri niyeti anlatır, anlamı zorlamaz: Saved kaydedilmiş mi yoksa önerilen mi olduğunu tek başına söylemez.
- Bildirim payload'ında tüm entity yerine yalnızca id ve version gibi sabit alanlar taşınmalı; get-only property'ler bunları korur.
- Field-like event'te abone yoksa delegate null olur ve çağrı sessizce atlanır; bu varsayılanın sözleşmede açıkça yazılması gerekir.
- Karar event'i tek sahip ister: örnek Func<int,bool> callback'ini zorunlu tutar ve birden fazla girdili invocation list'ini reddeder.
- Senkron handler istisnası sonraki handler'ları durdurur ve state değiştikten sonra oluşur; publisher bunu geri almaz.
- async void bir handler kararı iletemez; void dönen event sözleşmesi asenkron cevabı temsil edemez.
Bir event'in anlamı isminden değil, onu tetikleyen metottan gelir. Cosentino üç işi ayırıyor: Stored gibi geçmiş zamanlı bildirimler, TryReplace gibi bir işlemin ön koşulunu soran kararlar ve ara durum güncellemeleri. Bildirim payload'ı sabit olmalı: örnekte DocumentStoredArgs yalnızca documentId ve version taşıyor, get-only property'lerle korunuyor. Tüm mutable doküman nesnesini vermek, alıcıya gereğinden fazla yetki verir ve payload'ın ilk anı mı sonraki durumu mu anlattığını belirsizleştirir.
Karar gerektiren yerde tek bir sahip olmalı. İkinci örnek, mayReplace adlı Func<int,bool> callback'ini constructor'da zorunlu tutuyor ve birden fazla girdili bir invocation list'ini reddediyor; abone yoksa hiçbir şey olmuyor, çünkü null delegate çağrılmıyor ve işlem tamamlanıyor. Multicast delegate handler'ları sırayla ve senkron çalıştırır; bir handler'ın fırlattığı istisna sonrakileri engeller, üstelik state değiştikten sonra. async void handler ise karar veremez: dönen bir Task olmadığı için raiser sonucu göremez.
Gerçek dünyada kullanımı
- Dosya yükleme servisinde blob commit edildikten sonra yayınlanan bir Stored bildirimi; audit ve telemetri handler'ları yazma yolunu değiştirmeden tepki verir.
- Fiyatlandırma motorunda plan değişikliğini uygulamadan önce tek bir onay callback'i (Func<decimal,bool>) çalıştırmak ve onay yoksa hiçbir şey yazmamak.
- Masaüstü uygulamada doküman değişikliğini dinleyen UI handler'ları; bir handler patladığında diğer reaksiyonların sessizce iptal olmasını engellemek.
- Çok kiracılı bir API'de olay aboneliklerinin opsiyonel, yetkilendirmenin ise zorunlu bağımlılık olarak ayrılması.
Neden önemli
Bir event'in bildirim mi yoksa karar mı olduğunu netleştirmek, abone yokken oluşan davranışı ve bir handler patladığında işlemin ne olacağını öngörülebilir kılar. Aksi halde doğruluk, kimsenin sözleşmede görmediği bir abonelik kablolamasına bağlı kalır.