Rozšíření .Net Reactive poskytuje vývojářům sadu funkcí pro implementaci reaktivního programovacího modelu pro vývojáře .Net, aby bylo zpracování událostí jednodušší a výraznější pomocí deklarativních akcí. Zatímco klíčovými pilíři reaktivního škálování jsou IObserver a IObservable rozhraní, jako vývojář často nemusíte tato rozhraní implementovat sami. Knihovna podporuje vestavěný typ Subject<T>, který implementuje rozhraní a podporuje mnoho funkcí.
Témata jsou základem různých témat dostupných v knihovně a existují i další témata – ReplaySubject<T>, BehaviorSubject<T> a AsyncSubject<T>. Je užitečné pochopit zásadní rozdíly mezi nimi a jak je využít k lepšímu využití knihovny.
V tomto článku porovnáme Subjekt<T> a jeho sourozence a pokusíme se ilustrovat rozdíly v jejich chování.
Předmět<T>
Jak již bylo zmíněno, Subject<T> je základem dostupných témat, což umožňuje snadné používání knihovny bez nutnosti implementovat rozhraní IObservable<T> a IObserver<T> sami. Jednoduchá ukázka typu tématu je uvedena níže.
V kódu výše jsme vytvořili <T>instanci Subject, a protože implementuje<T> IObserver a IObserverable<T>, použijeme stejnou instanci k odběru a publikování hodnoty do IObserver. Dalším důležitým bodem je, jak používáme přetížení metody Subscribe k přijímání akcí jako vstupu. Toto se provádí pro každou zveřejněnou hodnotu, v tomto případě se číslo vytiskne do konzole.
Zkusme ukázat publikované hodnoty a hodnoty, které IObserver (v této akci) <T>vytiskne do konzole na následujícím obrázku. To nám pomůže snadno porovnat zbývající sourozence a varianty.
První řádek představuje zveřejněnou hodnotu a druhý řádek hodnotu přijatou IObserverem. Navíc jsme přidali řádek, který ukazuje, v jakém okamžiku se pozorovatel přihlásí k odběru streamu během vykonání. Tato čára je znázorněna svislou tečkovanou čarou.
V uvedeném kódu jsme si všimli, že pozorovatel se přihlásil k datovému toku před zveřejněním první hodnoty. Obrázek ukazuje linku Subscriber umístěnou před prvním prvkem. Jak vidíte z výstupní linky, nemá to na výstup (v tuto chvíli žádný vliv).
Ale co když pozorovatel přijímá data až poté, co byly některé hodnoty již zveřejněny? Má to vliv na data, která pozorovatelé přijímají? Než se podíváme na výstup, nejprve napišeme stejný kód.
V uvedeném kódu můžeme pozorovat, že pozorovatel se přihlašuje k datovému toku až po zveřejnění dvou hodnot (1 a 2). Jak se dalo očekávat, to způsobí, že pozorovatelé neobdrží data zveřejněná před zavoláním metody předplatného. Jak je znázorněno na obrázku níže.
Co když chcete číst všechny publikované hodnoty, i když se pozorovatel přihlásí pozdě? Právě zde<T> přichází na řadu ReplaySubject.
ReplaySubject<T>
ReplaySubject<T> ukládá hodnoty a přehrává je pro pozdější odběratele. To je užitečné pro vyhýbání se závodním podmínkám. Pojďme změnit předchozí kód tak, aby používal ReplaySubject,<T> a uvidíme, jak to ovlivní to, co pozorovatel přijímá.
Jak je ukázáno v kódu výše, v<T> <T>kódu se téměř nic nemění, kromě toho, že nyní používáme ReplaySubject místo subject. Následující diagram ilustruje dopad na data, která pozorovatel přijímá.
Jak je vidět na obrázku, cacheovaná hodnota je nyní přehrávána předplatiteli i v případě, že se odběratel přihlásí později. Samozřejmě, tato užitečná funkce má svou cenu. Tato implementace bude ukládat do mezipaměti každou hodnotu publikovanou předplatitelem, což může způsobit problémy se špatnou pamětí, pokud je množství dat výrazně větší.
ReplaySubject<T> však má více než jeden způsob, jak tento problém vyřešit. Pro účely tohoto příkladu se podíváme na dva příklady, které využijí velikost a časová omezení k omezení cacheované hodnoty.
Jako první případ použijeme velikost cache k omezení hodnoty cache. <T>Konstruktor ReplaySubject poskytuje přetížení, které přijímá celé číslo reprezentující velikost cache bufferu (maximální počet prvků). V našem příkladu změňme kód tak, aby omezil velikost cache na 1.
Všimněte si, jak používáme <T>přetížení konstruktoru ReplaySubject k určení velikosti cache jako 1. To omezuje cachování a zajišťuje, že je uložen pouze jeden prvek a nahrazen novým prvkem hned po zveřejnění. Dopad této změny je uveden níže.
Dalším způsobem, jak omezit cache, je omezit dobu uložené položky, nebo jinými slovy stanovit dobu expirace této položky.
Napišme kód, který ten příklad ilustruje.
Podobně jako v předchozím kódu používáme<T> přetížení konstruktoru ReplaySubject k určení doby expirace položek v cache. Abychom prokázali náš případ, zavedli jsme zpoždění mezi zveřejněním hodnot.
Protože trvá plných 1200 ms, než se pozorovatel přihlásí, všechny prvky, které překročí dobu expirace 1000ms, budou z cache odstraněny. V tomto příkladu to způsobí, že hodnota 1 bude odstraněna z cache a nebude přehrávána pozdním odběratelům. Jak je znázorněno na obrázku níže.
Existují <T>i další přetížení pro ReplaySubject, která poskytují větší flexibilitu a jemně ladí cacheované hodnoty, ale pro příklady ponecháme dva již výše zmíněné příklady.
BehaviourSubject<T>
BehaviourSubject <T>je velmi podobný ReplaySubject<T> v tom, že pomáhá s hodnotami cache. Ale je v tom zásadní rozdíl. BehaviourSubject<T> ukládá do mezipaměti pouze poslední zveřejněnou hodnotu. Než se do toho pustíme dál, pojďme napsat nějaký kód.
Pokud BehaviorSubject<T> ukládá do cache pouze jednu hodnotu (která je naposledy známá), jak se liší od ReplaySubject velikosti 1<T>? Následující diagram jasně odráží situaci výše uvedeného kódu.
To však není úplně pravda. Zde jsou dva důležité rozdíly, které je třeba pochopit. Prvním je přítomnost nesplácení. Všimněte si, že v kódu výše <T>uvádíme hodnotu 0 jako výchozí v konstruktoru BehaviourSubject. Pokud v cache neexistuje žádná hodnota (jinými slovy, žádná data nebyla zveřejněna před odběrem pozorovatele), výchozí hodnota se vrátí. To se liší od ReplaySubject, který má velikost 1 <T>a nemá žádnou hodnotu. Následující kód a vizuální zobrazení sekvence toto chování demonstrují.
Druhý rozdíl je v tom, jak se BehaviorSubject<T> a ReplaySubject<T> chovají při odběru dokončené sekvence. Když se po dokončení přihlásíte, BehaviorSubject <T> nebude mít žádnou hodnotu, jak je uvedeno v níže uvedeném kódu.
Předplatitelé mají zaručeno, že neobdrží žádnou hodnotu, protože předplatné probíhá až po dokončení.
<T>To je však případ ReplaySubject . Není zaručeno, že pozorovatel neobdrží žádné hodnoty, jak je uvedeno v níže uvedeném kódu.
Jak je uvedeno v kódu výše, cache je velká 1 a i když je předplatné vyvoláno po dokončení hovoru, cache zůstane (dokud není splněna podmínka expirace), takže v tomto případě bude přijata poslední zveřejněná hodnota.
AsyncSubject<T>
AsyncSubject <T>je poslední sourozenec subjektu, kterého v tomto článku prozkoumáme<T>, a je velmi podobný předchozím dvěma (ReplaySubject a BehaviourSubject) tím, že také ukládá výsledky do cache. Ale opět je tu zásadní rozdíl. AsyncSubject zveřejní poslední uloženou hodnotu pouze tehdy, pokud je sekvence označena jako kompletní <T> (cache pouze jednu hodnotu, poslední hodnotu).
Zvažte následující kód.
Tím vygeneruje hodnotu, kterou pozorovatel označí jako poslední hodnotu publikovanou před dokončením – hodnotu 4. Jak je znázorněno na obrázku níže.
Ale co se stane, když přeskočíme volání, které označí sekvenci jako dokončenou? Pojďme tu repliku zakomentovat a zkusit to znovu.
To negeneruje žádná data pro pozorovatele, protože AsyncSubject<T> zveřejní výsledky až poté, co je sekvence označena jako dokončená.
To je významný rozdíl, na který by měl každý, kdo používá AsyncSubject<T>, mít na paměti.
závěr
Tento článek ukazuje <T>rozdíly mezi různými sourozenci Subjektu a některé jeho varianty. Často je užitečné být si těchto jemných rozdílů vědom, protože pokud si to neuvědomujete, mohou vykazovat jiné, než jste čekali.
Původní odkaz:Přihlášení k hypertextovému odkazu je viditelné.
|
Zveřejněno 27.01.2024 12:17:19
|
|
|
|
Pronajímatel|
Zveřejněno 27.01.2024 12:19:47
|
