|
|
Zverejnené 27. 1. 2024 12:17:19
|
|
|
|
Rozšírenie .Net Reactive poskytuje vývojárom súbor funkcií na implementáciu reaktívneho programovacieho modelu pre .Net vývojárov, aby bolo spracovanie udalostí jednoduchšie a výraznejšie pomocou deklaratívnych akcií. Hoci kľúčovými piliermi reaktívneho škálovania sú IObserver a IObservable rozhrania, ako vývojár často nemusíte tieto rozhrania implementovať sami. Knižnica podporuje zabudovaný typ Subject<T>, ktorý implementuje rozhrania a podporuje mnoho funkcií.
Témy sú základom rôznych tém dostupných v knižnici a existujú aj ďalšie témy – ReplaySubject<T>, BehaviorSubject<T> a AsyncSubject<T>. Je užitočné pochopiť základné rozdiely medzi nimi a ako ich využiť na lepšie využitie knižnice.
V tomto článku porovnáme Subjekt<T> a jeho súrodenca, pričom sa pokúsime ilustrovať rozdiely v ich správaní.
Predmet<T>
Ako už bolo spomenuté, Subject<T> je základom dostupných tém, poskytuje jednoduchý spôsob používania knižnice bez nutnosti implementovať IObservable<T> a<T> IObserver rozhrania sami. Jednoduchá ukážka tohto typu témy je zobrazená nižšie.
V vyššie uvedenom kóde sme vytvorili <T>inštanciu Subject, a keďže implementuje<T> IObserver a IObserverable<T>, použijeme tú istú inštanciu na prihlásenie a publikovanie hodnoty do IObserver. Ďalším dôležitým bodom je, ako používame preťaženie metódy Subscribe na prijímanie akcií ako vstupu. Toto sa urobí pre každú publikovanú hodnotu, v tomto prípade sa číslo vytlačí do konzoly.
Skúsme ukázať publikované hodnoty a hodnoty, ktoré IObserver (v tejto akcii<T>) vytlačí do konzoly na nasledujúcom obrázku. To nám pomôže jednoducho porovnať zostávajúcich súrodencov a varianty.
Prvý riadok predstavuje publikovanú hodnotu a druhý riadok hodnotu prijatú IObserverom. Okrem toho sme pridali riadok, ktorý označuje, v kom bode sa pozorovateľ prihlási na stream počas vykonávania. Táto čiara je znázornená vertikálnou prerušovanou čiarou.
V kóde vyššie sme si všimli, že pozorovateľ sa prihlásil na dátový tok pred zverejnením prvej hodnoty. Obrázok zobrazuje linku Subscriber umiestnenú pred prvým prvkom. Ako vidíte z výstupnej linky, toto nemá žiadny vplyv na výstup (v tomto bode).
Ale čo ak pozorovateľ prihlási údaje až po tom, čo niektoré hodnoty už boli zverejnené? Má to vplyv na údaje, ktoré pozorovatelia prijímajú? Predtým, než sa pozrieme na výstup, najprv napíšme ten istý kód.
V uvedenom kóde môžeme pozorovať, že pozorovateľ sa prihlási na dátový tok až po zverejnení dvoch hodnôt (1 a 2). Ako by sa dalo očakávať, to spôsobí, že pozorovatelia nedostanú dáta publikované pred zavolaním metódy predplatného. Ako je znázornené na obrázku nižšie.
Čo ak chcete čítať všetky publikované hodnoty, aj keď sa pozorovateľ prihlási neskoro? Tu<T> prichádza na rad ReplaySubject.
ReplaySubject<T>
ReplaySubject<T> ukladá hodnoty a prehráva ich pre neskorších odberateľov. To je užitočné na vyhýbanie sa pretekárskym podmienkam. Zmeňme predchádzajúci kód tak, aby používal ReplaySubject<T> a uvidíme, ako to ovplyvní to, čo pozorovateľ dostane.
Ako je uvedené v kóde vyššie, v<T> <T>kóde sa takmer nič nemení, okrem toho, že teraz používame ReplaySubject namiesto subjektu. Nasledujúci diagram ilustruje vplyv na prijaté dáta pozorovateľom.
Ako je znázornené na obrázku, uložená hodnota sa teraz prehráva pre odberateľa, aj keď sa odberateľ prihlási neskôr. Samozrejme, táto užitočná funkcia má svoju cenu. Táto implementácia bude ukladať do vyrovnávacej pamäte každú hodnotu publikovanú odberateľom, čo môže spôsobiť problémy so zlou pamäťou, keď je množstvo dát výrazne väčšie.
ReplaySubject<T> však má viacero spôsobov, ako tento problém vyriešiť. Pre účely tohto príkladu sa pozrieme na dva príklady, ktoré použijú veľkostné a časové obmedzenia na obmedzenie cacheovanej hodnoty.
Ako v prvom prípade použijeme veľkosť cache na obmedzenie jej hodnoty. <T>Konštruktor ReplaySubject poskytuje preťaženie, ktoré prijíma celé číslo reprezentujúce veľkosť cache bufferu (maximálny počet prvkov). V našom príklade zmeňme kód tak, aby obmedzil veľkosť cache na 1.
Všimnite si, ako používame <T>preťaženie konštruktorov v ReplaySubject na uvedenie veľkosti cache ako 1. To obmedzuje cacheovanie a zabezpečuje, že je uložený len jeden prvok a nahradený novým hneď po zverejnení. Dopad tejto zmeny je uvedený nižšie.
Ďalším spôsobom, ako obmedziť cacheovanie, je obmedziť čas uloženej položky, alebo inými slovami, určiť čas expirácie pre uloženú položku.
Napíšme kód, ktorý tento príklad ilustruje.
Podobne ako v predchádzajúcom kóde, používame<T> preťaženie konštruktora ReplaySubject na určenie času expirácie položiek v cache. Aby sme preukázali náš prípad, zaviedli sme oneskorenie medzi zverejnením hodnôt.
Keďže trvá plných 1200ms, kým sa pozorovateľ prihlási, všetky prvky, ktoré prekročia čas expirácie 1000ms, budú z cache odstránené. V tomto príklade to spôsobí, že hodnota 1 bude z cache odstránená a nebude sa opakovať pre neskorých odberateľov. Ako je znázornené na obrázku nižšie.
Pre <T>ReplaySubject sú aj iné preťaženia, ktoré poskytujú väčšiu flexibilitu a jemne doladia uložené hodnoty, ale napríklad ponecháme už uvedené dva príklady.
BehaviourSubject<T>
BehaviourSubject <T>je veľmi podobný ReplaySubject<T> v tom, že pomáha s hodnotami cache. Ale je tu významný rozdiel. BehaviourSubject<T> ukladá len poslednú publikovanú hodnotu. Skôr než sa do toho pustíme ďalej, poďme napísať nejaký kód.
Ak BehaviorSubject<T> uchováva len jednu hodnotu (ktorá je naposledy známa), čím sa líši od ReplaySubject veľkosti 1<T>? Nasledujúci diagram jasne odráža situáciu vyššie uvedeného kódu.
To však nie je úplne pravda. Tu sú dva dôležité rozdiely, ktoré treba pochopiť. Prvým je prítomnosť defaultov. Všimnite si, že v vyššie uvedenom kóde uvádzame <T>hodnotu 0 ako predvolenú v konštruktore BehaviourSubject. Ak v cache neexistuje žiadna hodnota (alebo inými slovami, žiadne údaje neboli zverejnené pred prihlásením pozorovateľa), predvolená hodnota sa vráti. To sa líši od ReplaySubject, ktorý má veľkosť 1 <T>a nemá žiadnu hodnotu. Nasledujúci kód a vizuálna reprezentácia sekvencie toto správanie demonštrujú.
Druhý rozdiel je v tom, ako sa BehaviorSubject<T> a ReplaySubject<T> správajú pri prihlásení sa na dokončenú sekvenciu. Keď sa prihlásite na odber po dokončení, BehaviorSubject <T> nebude mať žiadnu hodnotu, ako je uvedené v kóde nižšie.
Predplatitelia majú zaručené, že nedostanú žiadnu hodnotu, pretože predplatné prebiehajú až po dokončení.
<T>Avšak to je prípad ReplaySubject. Nie je zaručené, že pozorovateľ nedostane žiadne hodnoty, ako je uvedené v kóde nižšie.
Ako je uvedené v kóde vyššie, cache má veľkosť 1 a aj keď je predplatné vyvolané po dokončení hovoru, cache zostane (kým nie je splnená podmienka expirácie), takže v tomto prípade bude prijatá posledná publikovaná hodnota.
AsyncSubject<T>
AsyncSubject <T>je posledným súrodencom Subjektu, ktorého budeme skúmať v tomto článku<T>, a je veľmi podobný predchádzajúcim dvom (ReplaySubject a BehaviourSubject) v tom, že tiež cachuje výsledky. Ale opäť je tu výrazný rozdiel. AsyncSubject zverejňuje poslednú uloženú hodnotu len vtedy, ak je sekvencia označená ako úplná <T> (cache len jednu hodnotu, poslednú hodnotu).
Zvážte nasledujúci kód.
Tým sa vygeneruje hodnota pre pozorovateľa, že sekvencia je označená ako posledná hodnota publikovaná pred dokončením – hodnota 4. Ako je znázornené na obrázku nižšie.
Ale čo sa stane, ak vynecháme hovor, ktorý označuje sekvenciu ako kompletnú? Skúsme to znova.
Toto negeneruje žiadne dáta pre pozorovateľa, pretože AsyncSubject<T> publikuje výsledky až po označení sekvencie ako úplnej.
Toto je významný rozdiel, na ktorý by mal myslieť každý, kto používa AsyncSubject<T>.
záver
Tento článok ukazuje <T>rozdiely medzi rôznymi súrodencami Subjektu a niektoré jeho variácie. Často je užitočné byť si vedomý týchto jemných rozdielov, pretože ak si to neuvedomujete, môžu prejavovať iné správanie, než ste očakávali.
Pôvodný odkaz:Prihlásenie na hypertextový odkaz je viditeľné.
|
Predchádzajúci:.NET/C# kontroluje, či je k dispozícii TCP portBudúci:NSIS (1) Vytvorte jednoduchý inštalátor
|
Prenajímateľ|
Zverejnené 27. 1. 2024 12:19:47
|
