Extensia .Net Reactive oferă dezvoltatorilor un set de funcționalități pentru a implementa un model de programare reactivă pentru dezvoltatorii .Net, pentru a face gestionarea evenimentelor mai simplă și mai expresivă folosind acțiuni declarative. Deși pietrele cheie ale scalării reactive sunt interfețele IObserver și IObservable, ca dezvoltator, adesea nu trebuie să implementezi aceste interfețe singur. Biblioteca suportă tipul încorporat Subject<T>, care implementează interfețe și suportă multe funcții.
Temele stau la baza diferitelor subiecte disponibile în bibliotecă, iar alte teme sunt - <T>ReplaySubject,<T> BehaviorSubject și <T>AsyncSubject. Este util să înțelegi diferențele esențiale dintre ele și cum să le folosești pentru a folosi mai bine biblioteca.
În acest articol, vom compara<T> Subiectul cu fratele său, încercând să ilustrăm diferențele dintre comportamentul lor.
Subiect<T>
După cum s-a menționat anterior, Subject<T> stă la baza temelor disponibile, oferind o modalitate ușoară de a folosi biblioteca fără a implementa<T> singur interfețele IObservable și<T> IObserver. O demonstrație simplă a tipului de temă este prezentată mai jos.
În codul de mai sus, am creat o <T>instanță de Subject și, deoarece implementează<T> IObserver și IObserverable<T>, folosim aceeași instanță pentru a te abona și a publica valoarea pe IObserver. Un alt aspect important de remarcat aici este modul în care folosim supraîncărcarea metodei Subscribe pentru a accepta acțiuni ca intrare. Acest lucru se va face pentru fiecare valoare publicată, în acest caz tipărind numărul pe consolă.
Să încercăm să arătăm valorile publicate și valorile pe care IObserver (în această Acțiune<T>) le tipărește către consolă în imaginea următoare. Acest lucru ne va ajuta să comparăm ușor frații și variantele rămase.
Prima linie reprezintă valoarea publicată, iar a doua linie reprezintă valoarea primită de IObserver. În plus, am adăugat o linie care indică în ce moment observatorul se abonează la flux în timpul execuției. Această linie este reprezentată printr-o linie punctată verticală.
În codul de mai sus, am observat că observatorul s-a abonat la fluxul de date înainte de a publica prima valoare. Imaginea arată linia de abonat plasată înaintea primului element. După cum se vede din linia de ieșire, acest lucru nu are niciun efect asupra ieșirii (în acest moment).
Dar ce se întâmplă dacă observatorul se abonează la date doar după ce unele valori au fost deja publicate? Are acest lucru un impact asupra datelor primite de observatori? Înainte să ne uităm la rezultat, să scriem mai întâi același cod.
În codul de mai sus, putem observa că observatorul se abonează la fluxul de date doar după ce două valori (1 și 2) sunt publicate. Așa cum era de așteptat, acest lucru va determina observatorii să nu primească datele publicate înainte de a apela la metoda de abonament. Așa cum se vede în figura de mai jos.
Ce se întâmplă dacă vrei să citești toate valorile publicate, chiar dacă observatorul se abonează târziu? Aici<T> intervine ReplaySubject.
ReluareSubiect<T>
ReplaySubject<T> stochează valorile în cache și le redă pentru abonații următori. Acest lucru este util pentru a evita condițiile de cursă. Să schimbăm codul anterior pentru a folosi<T> ReplaySubject și să vedem cum afectează ceea ce primește observatorul.
Așa cum se arată în codul de mai sus,<T> <T>aproape că nu există nicio schimbare în cod, cu excepția faptului că acum folosim ReplaySubject în loc de subject. Diagrama următoare ilustrează impactul asupra datelor primite de observator.
Așa cum se arată în imagine, valoarea stocată în cache este acum redată către abonat, chiar dacă acesta se abonează ulterior. Desigur, această funcție utilă are un preț. Această implementare va stoca în cache fiecare valoare publicată de abonat, ceea ce poate cauza probleme de memorie defectă atunci când cantitatea de date este semnificativ mai mare.
Totuși, ReplaySubject<T> are mai multe modalități de a rezolva această problemă. Pentru acest exemplu, vom analiza două exemple care vor folosi constrângeri de dimensiune și timp pentru a limita valoarea stocată în cache.
În primul caz, vom folosi dimensiunea cache-ului pentru a limita valoarea cache-ului. <T>Constructorul ReplaySubject oferă o suprasarcină, care acceptă un întreg ce reprezintă dimensiunea bufferului cache-ului (numărul maxim de elemente). În exemplul nostru, să schimbăm codul pentru a limita dimensiunea cache-ului la 1.
Observați cum folosim <T>supraîncărcarea constructorului din ReplaySubject pentru a oferi dimensiunea Cache-ului ca 1. Acest lucru limitează cache-ul și asigură că doar un element este stocat în cache și înlocuit cu un element nou imediat ce este publicat. Impactul schimbării este prezentat mai jos.
O altă modalitate de a limita cache-ul este să limitezi timpul pentru obiectul stocat în cache sau, cu alte cuvinte, să oferi un timp de expirare pentru obiectul stocat.
Hai să scriem cod pentru a ilustra acest exemplu.
Similar codului anterior, folosim<T> supraîncărcarea constructorului ReplaySubject pentru a specifica timpul de expirare al elementelor din cache. Pentru a demonstra cazul nostru, am introdus o întârziere între eliberarea valorilor.
Deoarece observatorul se abonează la 1200ms întregi, orice element care depășește timpul de expirare de 1000ms va fi eliminat din cache. În acest exemplu, acest lucru va face ca valoarea 1 să fie eliminată din cache și nu va fi reluată abonaților întârziați. Așa cum se vede în figura de mai jos.
<T>Există și alte suprasolicitări pentru ReplaySubject care oferă mai multă flexibilitate și ajustează fin valorile cache-ului, dar pentru exemple, vom păstra cele două exemple deja acoperite mai sus.
ComportamentSubiect<T>
BehaviourSubject <T>este foarte asemănător cu<T> ReplaySubject prin faptul că ajută la stocarea valorilor. Dar există o diferență semnificativă. BehaviourSubject<T> stochează în cache doar ultima valoare publicată. Înainte să intrăm mai departe, să scriem cod.
Dacă BehaviorSubject<T> stochează în cache doar o singură valoare (care este ultima dată cunoscută), cu ce diferă de un ReplaySubject de dimensiunea 1<T>? Diagrama următoare reflectă clar situația codului de mai sus.
Totuși, acest lucru nu este complet adevărat. Există două diferențe importante de înțeles aici. Primul este prezența neplăților. Rețineți că în codul de mai sus, <T>oferim valoarea 0 ca implicit în constructorul BehaviourSubject. Dacă nu există nicio valoare în cache (sau, cu alte cuvinte, nu au fost publicate date înainte ca observatorul să se aboneze), valoarea implicită va fi returnată. Aceasta este diferită de ReplaySubject, care are dimensiunea 1<T>, dar nu are nicio valoare. Codul următor și o reprezentare vizuală a secvenței demonstrează acest comportament.
A doua diferență este modul în care se<T> comportă BehaviorSubject și<T> ReplaySubject atunci când se abonează la o secvență completă. Când vă abonați după finalizare, BehaviorSubject <T> nu va avea nicio valoare, așa cum este indicat în codul de mai jos.
Abonații nu vor primi nicio valoare deoarece abonamentele apar după finalizare.
Totuși, <T>acesta este cazul cu ReplaySubject. Nu există nicio garanție că observatorul nu va primi niciun valoare, așa cum este prezentat în codul de mai jos.
După cum se arată în codul de mai sus, cache-ul are o dimensiune de 1 și, chiar dacă abonamentul este apelat după finalizarea apelului, cache-ul va rămâne (până când se îndeplinește condiția de expirare), astfel încât în acest caz va fi primită ultima valoare publicată.
AsyncSubject<T>
<T>AsyncSubject este ultimul frate al Subiectului pe care îl vom explora în acest <T>articol și este foarte asemănător cu cele două anterioare (ReplaySubject și BehaviourSubject) prin faptul că stochează și rezultatele în cache. Dar, din nou, există o diferență semnificativă. AsyncSubject publică ultima valoare stocată în cache doar dacă secvența este marcată ca <T> completă (stochează în cache doar o singură valoare, ultima valoare).
Ia în considerare următorul cod.
Aceasta va genera o valoare pentru observator pe care secvența este marcată ca ultima valoare publicată înainte de finalizare - valoarea 4. Așa cum se vede în figura de mai jos.
Dar ce se întâmplă dacă sărim peste apelul care marchează secvența ca fiind completă? Hai să comentăm linia și să încercăm din nou.
Aceasta nu generează date pentru observator deoarece AsyncSubject<T> publică rezultatele doar după ce secvența este marcată ca completă.
Aceasta este o diferență semnificativă pe care oricine folosește <T>AsyncSubject ar trebui să o țină cont.
concluzie
Acest articol demonstrează <T>diferențele dintre diferiții frați ai Subiectului și unele dintre variațiile sale. Este adesea util să fii conștient de aceste diferențe subtile, deoarece pot manifesta comportamente diferite față de cele la care te așteptai dacă nu realizezi.
Link original:Autentificarea cu hyperlink este vizibilă.
|
Postat pe 27.01.2024 12:17:19
|
|
|
|
Proprietarul|
Postat pe 27.01.2024 12:19:47
|
