|
|
Julkaistu 27.1.2024 12.17.19
|
|
|
|
.Net Reactive Extension tarjoaa kehittäjille joukon ominaisuuksia reaktiivisen ohjelmointimallin toteuttamiseen .Net-kehittäjille, jotta tapahtumien käsittely olisi helpompaa ja ilmeikkäämpää deklaratiivisten toimintojen avulla. Vaikka reaktiivisen skaalauksen keskeiset kulmakivet ovat IObserver- ja IObservable-rajapinnat, kehittäjänä sinun ei usein tarvitse toteuttaa näitä rajapintoja itse. Kirjasto tukee sisäänrakennettua <T>Subject-tyyppiä, joka toteuttaa rajapinnat ja monia toimintoja.
Teemat muodostavat pohjan kirjastossa saatavilla oleville eri aiheille, ja on muitakin teemoja – ReplaySubject<T>, BehaviorSubject<T> ja <T>AsyncSubject. On hyödyllistä ymmärtää niiden olennaiset erot ja oppia, miten niitä voi hyödyntää kirjastoa paremmin.
Tässä artikkelissa vertaamme Subjektia<T> ja hänen sisarustaan, pyrkien havainnollistamaan heidän käyttäytymisensä eroja.
Aihe<T>
Kuten aiemmin mainittiin, Subject<T> toimii saatavilla olevien teemojen perustana, tarjoten helpon tavan käyttää kirjastoa ilman, että tarvitsee toteuttaa IObservable<T>- ja IObserver-rajapintoja<T> itse. Alla on yksinkertainen esimerkki teematyypistä.
Yllä olevassa koodissa loimme <T>Subject-instanssin, ja koska se toteuttaa<T> IObserverin ja <T>IObserverablen, käytetään samaa instanssia tilataksesi ja julkaistakseni arvon IObserverille. Toinen tärkeä huomioitava seikka on, miten käytämme Subscribe-metodin ylikuormitusta hyväksyäksemme toiminnot syötteenä. Tämä tehdään jokaiselle julkaistulle arvolle, tässä tapauksessa tulostamalla numero konsolille.
Yritetään näyttää julkaistut arvot ja ne arvot, jotka IObserver (tässä <T>Toiminnossa) tulostaa konsolille seuraavassa kuvassa. Tämä auttaa meitä helposti vertailemaan jäljellä olevia sisaruksia ja variantteja.
Ensimmäinen rivi edustaa julkaistua arvoa ja toinen rivi IObserverin vastaanottamaa arvoa. Lisäksi olemme lisänneet rivin, joka osoittaa, milloin tarkkailija tilaa virran suorituksen aikana. Tämä viiva esitetään pystysuoralla katkoviivalla.
Yllä olevassa koodissa huomasimme, että havaitsija tilasi datavirran ennen ensimmäisen arvon julkaisemista. Kuvassa on tilaajalinja, joka on asetettu ensimmäisen elementin eteen. Kuten näet lähtölinjasta, tällä ei ole vaikutusta lähtöön (tässä vaiheessa).
Mutta entä jos havaitsija tilaa tiedot vasta sen jälkeen, kun jotkin arvot on jo julkaistu? Vaikuttaako tämä havainnoijien vastaanottamiin tietoihin? Ennen kuin katsomme tulosta, kirjoitetaan sama koodi ensin.
Yllä olevassa koodissa voidaan havaita, että havaitsija tilaa datavirran vasta sen jälkeen, kun kaksi arvoa (1 ja 2) on julkaistu. Kuten voi odottaa, tämä aiheuttaa sen, että tarkkailijat eivät saa julkaistua dataa ennen tilausmenetelmän kutsumista. Kuten alla olevassa kuvassa näkyy.
Entä jos haluat lukea kaikki julkaistut arvot, vaikka tarkkailija tilaisi myöhässä? Tässä kohtaa ReplaySubject<T> astuu kuvaan.
ToistoAihe<T>
ReplaySubject<T> välimuistittaa arvot ja toistaa ne myöhemmille tilaajille. Tämä on hyödyllistä kilpailuolosuhteiden välttämisessä. Muutetaan aiempi koodi käyttämään<T> ReplaySubjectia ja katsotaan, miten se vaikuttaa siihen, mitä tarkkailija vastaanottaa.
Kuten yllä olevassa koodissa näkyy, koodissa ei<T> <T>juuri ole muutosta, paitsi että käytämme nyt ReplaySubjectia subjektin sijaan. Seuraava kaavio havainnollistaa havainnoijan saamaa datan vaikutusta.
Kuten kuvassa näkyy, välimuistissa ollut arvo toistetaan nyt tilaajalle, vaikka tilaaja tilaisi sen myöhemmin. Tietenkin tämä hyödyllinen ominaisuus maksaa hintansa. Tämä toteutus välimuistittaa kaikki tilaajan julkaisemat arvot, mikä voi aiheuttaa huonoja muistiongelmia, kun datamäärä on huomattavasti suurempi.
<T> ReplaySubjectilla on kuitenkin useampi tapa ratkaista tämä ongelma. Tämän esimerkin vuoksi tarkastelemme kahta esimerkkiä, joissa käytetään koko- ja aikarajoitteita välimuistissa olevan arvon rajoittamiseen.
Ensimmäisessä tapauksessa käytämme välimuistin kokoa rajoittamaan välimuistin arvoa. <T>ReplaySubjectin konstruktori tarjoaa ylikuormituksen, joka hyväksyy kokonaisluvun, joka edustaa välimuistipuskurin kokoa (maksimielementtimäärä). Esimerkissämme muutetaan koodia niin, että välimuistin koko rajoitetaan arvoon 1.
Huomaa, miten <T>käytämme ReplaySubjectin konstruktoriylikuormitusta antaaksemme välimuistin koon 1. Tämä rajoittaa välimuistia ja varmistaa, että vain yksi elementti välimuistitetaan ja korvataan uudella alkiolla heti julkaisun jälkeen. Muutoksen vaikutus on esitetty alla.
Toinen tapa rajoittaa välimuistia on rajoittaa välimuistissa olevan kohteen aikaa, toisin sanoen antaa välimuistille viimeinen käyttöaika.
Kirjoitetaan koodi havainnollistamaan tätä esimerkkiä.
Kuten aiemmassa koodissa, käytämme<T> ReplaySubject-konstruktorin ylikuormitusta määrittämään välimuistissa olevien kohteiden vanhenemisajan. Todistaaksemme perustelumme lisäsimme viiveen arvojen julkaisun väliin.
Koska tarkkailijan tilaaminen kestää kokonaiset 1200 ms, kaikki alkiot, jotka ylittävät 1000 ms vanhentumisajan, poistetaan välimuistista. Tässä esimerkissä arvo 1 poistetaan välimuistista eikä sitä toisteta myöhäisille tilaajille. Kuten alla olevassa kuvassa näkyy.
<T>ReplaySubjectille on myös muita ylikuormituksia, jotka tarjoavat enemmän joustavuutta ja hienosäätävät välimuistissa olevia arvoja, mutta esimerkiksi pidämme jo mainitut kaksi esimerkkiä.
KäytösSubjekti<T>
BehaviourSubject <T>on hyvin samanlainen kuin ReplaySubject<T> siinä, että se auttaa arvojen välimuistissa. Mutta ero on merkittävä. BehaviourSubject<T> välimuistittaa vain viimeksi julkaistun arvon. Ennen kuin mennään tähän pidemmälle, kirjoitetaan vähän koodia.
Jos BehaviorSubject<T> välimuistittaa vain yhden arvon (joka on viimeksi tunnettu), miten se eroaa ReplaySubjectista, jonka koko on 1<T>? Seuraava kaavio heijastaa selvästi yllä olevan koodin tilannetta.
Tämä ei kuitenkaan ole täysin totta. Tässä on kaksi tärkeää eroa, jotka on ymmärrettävä. Ensimmäinen on oletusten esiintyminen. Huomaa, että yllä olevassa koodissa <T>annamme arvon 0 oletuksena BehaviourSubjectin konstruktoriin. Jos välimuistissa ei ole arvoa (tai toisin sanoen, dataa ei ole julkaistu ennen tarkkailijan tilaamista), oletusarvo palautetaan. Tämä eroaa ReplaySubjectista, jonka koko on 1<T>, eikä sillä ole arvoa. Seuraava koodi ja sekvenssin visuaalinen esitys osoittavat tämän käyttäytymisen.
Toinen ero on, miten BehaviorSubject<T> ja ReplaySubject<T> käyttäytyvät, kun tilataan valmiin sekvenssin. Kun tilaat tilauksen suorittamisen jälkeen, <T> BehaviorSubjectilla ei ole arvoa, kuten alla olevassa koodissa näkyy.
Tilaajat eivät saa arvoa, koska tilaukset syntyvät vasta valmistumisen jälkeen.
Tämä <T>kuitenkin pätee ReplaySubjectiin. Ei ole takeita siitä, etteikö havaitsija saa arvoja, kuten alla olevassa koodissa on esitetty.
Kuten yllä olevassa koodissa on esitetty, välimuisti on kooltaan 1, ja vaikka tilaus kutsuttaisiin kutsun jälkeen, välimuisti säilyy (kunnes vanhenemisehto täyttyy), joten tässä tapauksessa viimeksi julkaistu arvo vastaanotetaan.
AsyncSubject<T>
AsyncSubject <T>on Subjektin viimeinen sisarus, jota käsittelemme tässä <T>artikkelissa, ja se on hyvin samankaltainen kuin kaksi edellistä (ReplaySubject ja BehaviourSubject) siinä, että se myös välimuistittaa tuloksia. Mutta jälleen on merkittävä ero. AsyncSubject julkaisee viimeksi välimuistissa olevan arvon vain, jos jono on merkitty <T> täydelliseksi (se välimuistittaa vain yhden arvon, viimeisen arvon).
Tarkastellaan seuraavaa koodia.
Tämä tuottaa havaitsijalle arvon, että jono on merkitty viimeiseksi ennen valmistumista julkaistuksi arvoksi – arvo 4. Kuten alla olevassa kuvassa näkyy.
Mutta mitä tapahtuu, jos ohitamme kutsun, joka merkitsee jonon täydelliseksi? Kommentoidaan rivi ja yritetään uudelleen.
Tämä ei tuota havaitsijalle dataa, koska AsyncSubject<T> julkaisee tulokset vasta, kun sekvenssi on merkitty valmiiksi.
Tämä on merkittävä ero, joka jokaisen AsyncSubjectia <T>käyttävän tulisi pitää mielessä.
johtopäätös
Tämä artikkeli <T>havainnollistaa Subjektin eri sisarusten ja joidenkin sen muunnelmien eroja. On usein hyödyllistä olla tietoinen näistä hienovaraisista eroista, sillä ne voivat käyttäytyä eri tavalla kuin odotit, jos et sitä huomaa.
Alkuperäinen linkki:Hyperlinkin kirjautuminen on näkyvissä.
|
Edellinen:.NET/C# tarkistaa, onko TCP-portti saatavillaSeuraava:NSIS (1) Tee yksinkertainen asennusohjelma
|
Vuokraisäntä|
Julkaistu 27.1.2024 12.19.47
|
