.Net Reaktif Uzantısı, geliştiricilere .Net geliştiricileri için olay yönetimini daha basit ve ifade edici hale getirmek için bir dizi özellik sunar; böylece olay işleme daha basit ve ifade edilebilir hale getirilir. Tepkisel ölçeklendirmenin temel taşları IObserver ve IObservable arayüzler olsa da, bir geliştirici olarak bu arayüzleri genellikle kendiniz uygulamanıza gerek kalmaz. Kütüphane, <T>arayüzleri uygulayan ve birçok işlevi destekleyen yerleşik tip Subject'ı destekler.
Temalar kütüphanedeki farklı konuların temelini oluşturur ve başka temalar da vardır - ReplaySubject<T>, BehaviorSubject<T> ve <T>AsyncSubject. Aralarındaki temel farkları anlamak ve kütüphaneyi daha iyi kullanmak için bunları nasıl kullanacağınızı anlamak faydalıdır.
Bu makalede, Konu<T> ile kardeşini karşılaştıracak ve davranışları arasındaki farkları göstermeye çalışacağız.
Konu<T>
Daha önce belirtildiği gibi, Subject<T> mevcut temaların temelini oluşturur ve IObservable<T> ile IObserver arayüzlerini kendiniz uygulamaya gerek kalmadan kütüphaneyi kolayca kullanmanızı sağlar<T>. Aşağıda tema türünün basit bir gösterimi gösterilmiştir.
Yukarıdaki kodda <T>Subject'ın bir örneğini oluşturduk ve<T> IObserver ile IObserverable'ı <T>uyguladığı için aynı örneği kullanarak değeri IObserver'a abone edip yayınladık. Burada dikkat edilmesi gereken bir diğer önemli nokta ise, Abone Ol' yönteminin aşırı yüklenmesini eylemleri giriş olarak kabul etmek için nasıl kullandığımızdır. Bu, her yayınlanan değer için yapılır, bu durumda numara konsola basılır.
Yayınlanan değerleri ve IObserver'ın (bu <T>Eylemde) konsola yazdırdığı değerleri aşağıdaki görselde göstermeye çalışalım. Bu, kalan kardeşleri ve varyantları kolayca karşılaştırmamıza yardımcı olacak.
İlk satır yayınlanan değeri, ikinci satır ise IObserver tarafından alınan değeri temsil eder. Ayrıca, gözlemcinin yayını uygulama sırasında hangi noktada abone olduğunu gösteren bir satır ekledik. Bu çizgi, dikey noktalı bir çizgiyle temsil edilir.
Yukarıdaki kodda, gözlemcinin ilk değeri yayınlamadan önce veri akışına abone olduğunu fark ettik. Görsel, ilk elemanın önüne yerleştirilen Abone hattını gösterir. Çıkış hattından da görebileceğiniz gibi, bu çıkış üzerinde hiçbir etkisi yok (şu noktada).
Peki ya gözlemci, bazı değerler zaten yayınlandıktan sonra verilere abone olursa? Bu, gözlemcilerin aldığı verileri etkiler mi? Çıktıya bakmadan önce, önce aynı kodu yazalım.
Yukarıdaki kodda, gözlemcinin veri akışına ancak iki değer (1 ve 2) yayınlandıktan sonra abone olduğunu gözlemleyebiliriz. Beklendiği gibi, bu durum gözlemcilerin abonelik yöntemini çağırmadan önce yayınlanan verileri almamasına neden olur. Aşağıdaki şekilde gösterildiği gibi.
Ya gözlemci geç abone olsa bile, yayınlanan tüm değerleri okumak isterseniz? İşte burada ReplaySubject<T> devreye giriyor.
Tekrar Oynatma Konusu<T>
ReplaySubject<T> değerleri önbelleer ve sonraki aboneler için tekrar oynatır. Bu, yarış koşullarından kaçınmak için faydalıdır. Önceki kodu ReplaySubject kullanacak şekilde<T> değiştirelim ve bunun gözlemcinin aldığı şeyi nasıl etkilediğine bakalım.
Yukarıdaki kodda gösterildiği gibi,<T> <T>kodda neredeyse hiç değişiklik yok, sadece artık konu yerine ReplaySubject kullanıyoruz. Aşağıdaki diyagram, gözlemcinin aldığı veriler üzerindeki etkisini göstermektedir.
Görselde gösterildiği gibi, önbelleğe alınan değer artık aboneye tekrar oynatılır, abone daha sonra abone olsa bile. Elbette, bu faydalı özelliğin bir bedeli var. Bu uygulama, abone tarafından yayımlanan her değeri önbelleyer; bu da veri miktarı önemli ölçüde daha büyük olduğunda kötü bellek sorunlarına yol açabilir.
Ancak ReplaySubject'ın<T> bu sorunu çözmenin birden fazla yolu vardır. Bu örnek için, önbelleğe alınan değeri sınırlamak için boyut ve zaman kısıtlamaları kullanan iki örneğe bakacağız.
İlk örnek olarak, önbelleğin değerini sınırlamak için önbellek boyutunu kullanacağız. <T>ReplaySubject'ın yapıcısı, önbellek tamponunun boyutunu (maksimum eleman sayısı) temsil eden bir tam sayı kabul eden bir aşırı yükleme sağlar. Örneğimizde, önbellek boyutunu 1 ile sınırlayacak kodu değiştirelim.
<T>ReplaySubject'ın yapıcı aşırı yükünü kullanarak önbellek boyutunu 1 olarak sağladığımıza dikkat edin. Bu, önbelleklemeyi sınırlar ve yalnızca bir elemanın önbelleğe alınıp yayınlandığı anda yeni bir elemanla değiştirilmesini sağlar. Değişikliğin etkisi aşağıda gösterilmiştir.
Önbelleklemeyi sınırlamanın bir diğer yolu, önbelleklenen öğenin süresini sınırlamak, yani önbelleklenen öğe için bir son kullanma süresi sağlamaktır.
Bu örneği göstermek için kod yazalım.
Önceki kodda benzer şekilde,<T> önbellekteki öğelerin son kullanma süresini belirtmek için ReplaySubject oluşturucusunun aşırı yükünü kullanıyoruz. Kendi durumumuzu göstermek için, değerlerin yayımlanması arasında bir gecikme getirdik.
Gözlemcinin abone olması tam 1200ms sürdüğü için, 1000ms son kullanma süresini aşan tüm elemanlar önbellekten çıkarılır. Bu örnekte, bu değer 1'in önbellekten kaldırılmasına ve geç abonelere tekrar oynatılmasına yol açacaktır. Aşağıdaki şekilde gösterildiği gibi.
<T>ReplaySubject için daha fazla esneklik sağlayan ve önbelleğe alınan değerleri ince ayar eden başka aşırı yüklemeler de var, ancak örnekler olarak, yukarıda ele alınan iki örneği de koruyacağız.
DavranışKonu<T>
BehaviourSubject<T>,<T> değerleri önbelleğe atmaya yardımcı olması bakımından ReplaySubject'a çok benzer. Ama önemli bir fark var. BehaviourSubject<T> yalnızca son yayımlanan değeri önbelleyer. Daha fazla girmeden önce biraz kod yazalım.
Eğer Davranış Konusu<T> yalnızca tek bir değeri önbellemişse (ki bu en son biliniyor), 1 boyuttaki bir ReplaySubject'ten nasıl <T>farklıdır? Aşağıdaki diyagram, yukarıdaki kodun durumunu açıkça yansıtmaktadır.
Ancak bu tamamen doğru değildir. Burada anlaşılması gereken iki önemli fark var. İlki, temerrütlerin varlığı. Yukarıdaki kodda, <T>BehaviorSubject oluşturucusunda varsayılan olarak 0 değeri verildiğini unutmayın. Önbellekte herhangi bir değer yoksa (yani gözlemci abone olmadan önce veri yayınlanmadıysa), varsayılan değer döner. Bu, ReplaySubject'in 1 <T>boyutuna sahip ve hiçbir değeri olmayan bir şeyden farklıdır. Aşağıdaki kod ve dizinin görsel temsili bu davranışı gösterir.
İkinci fark, tamamlanmış bir diziye abone olduklarında BehaviorSubject<T> ve ReplaySubject<T> davranışlarıdır. Tamamlandıktan sonra abone olduğunuzda, aşağıdaki kodda gösterildiği gibi Davranış Konusu <T> değeri olmaz.
Abonelerin herhangi bir değer almaması garantisi vardır çünkü abonelikler tamamlandıktan sonra gerçekleşir.
Ancak <T>ReplaySubject için durum böyle. Aşağıdaki kodda gösterildiği gibi, gözlemcinin herhangi bir değer almayacağına dair bir garanti yoktur.
Yukarıdaki kodda gösterildiği gibi, önbellek 1 boyutta olup abonelik çağrısı tamamlandıktan sonra çağrılsa bile, önbellek (son kullanma koşulu sağlanana kadar) kalır, bu durumda son yayınlanan değer alınır.
AsenkronKonu<T>
AsyncSubject<T>, bu makalede inceleyeceğimiz Konu'nun son kardeşidir <T>ve önceki iki kardeşe (ReplaySubject ve Davranış Konusu) çok benzer, çünkü sonuçları önbellemektedir. Ama yine de önemli bir fark var. AsyncSubject, yalnızca dizis tamamlanmış olarak işaretlenmişse (yalnızca <T> bir değeri, son değeri önbellekler) son önbelleklenmiş değeri yayınlar.
Aşağıdaki kodu düşünün.
Bu, gözlemci için dizinin tamamlanmadan önce yayınlanan son değer olarak işaretlendiği bir değer - 4 değeri oluşturur. Aşağıdaki şekilde gösterildiği gibi.
Peki diziyi tamamlanmış olarak işaretleyen çağrıyı atlarsak ne olur? Çizgiyi yorumlayalım ve tekrar deneyelim.
Bu, gözlemci için herhangi bir veri üretmez çünkü AsyncSubject<T> sonuçları yalnızca dizis tamamlanmış olarak işaretlendikten sonra yayımlar.
Bu, AsyncSubject kullanan herkesin aklında tutması gereken önemli bir <T>farktır.
son
Bu makale, <T>Subject'ın çeşitli kardeşleri ve bazı varyasyonları arasındaki farkları göstermektedir. Bu ince farklılıkların farkında olmak genellikle faydalıdır, çünkü farkında olmazsanız beklediğinizden farklı davranışlar gösterebilirler.
Orijinal bağlantı:Bağlantı girişi görünür.
|
Yayınlandı 27.01.2024 12:17:19
|
|
|
|
Ev sahibi|
Yayınlandı 27.01.2024 12:19:47
|
