|
|
Postitatud 27.01.2024 12:17:19
|
|
|
|
.Net Reactive Extension pakub arendajatele hulga funktsioone, et rakendada reaktiivset programmeerimismudelit, et muuta sündmuste käsitlemine deklaratiivsete toimingute abil lihtsamaks ja väljendusrikkamaks. Kuigi reaktiivse skaleerimise peamised nurgakivid on IObserver ja IObservable liidesed, ei pea arendajana sageli neid liideseid ise rakendama. Raamatukogu toetab sisseehitatud tüüpi <T>Subjekti, mis rakendab liideseid ja toetab mitmeid funktsioone.
Teemad on aluseks erinevatele teemadele raamatukogus ning on ka teisi teemasid – ReplaySubject<T>,<T> BehaviorSubject ja AsyncSubject<T>. Kasulik on mõista nende olulisi erinevusi ja kuidas neid kasutada raamatukogu paremaks kasutamiseks.
Selles artiklis võrdleme<T> Subjekti ja tema õde-venda, püüdes illustreerida nende käitumise erinevusi.
Teema<T>
Nagu varem mainitud, on Subject<T> aluseks saadaolevatele teemadele, pakkudes lihtsat viisi teegi kasutamiseks ilma, et peaksid ise IObservable'i<T> ja IObserveri<T> liideseid rakendama. Allpool on näidatud lihtne näide teematüübist.
Ülaltoodud koodis lõime <T>Subject'i eksemplari ja kuna see rakendab<T> IObserverit ja <T>IObserverable'i, kasutame sama instantsi, et väärtus IObserveris tellida ja avaldada. Veel üks oluline punkt siin on see, kuidas me kasutame Subscribe meetodi ülekoormust, et aktsepteerida tegevusi sisendina. See tehakse iga avaldatud väärtuse puhul, antud juhul printides number konsoolile.
Proovime näidata avaldatud väärtusi ja väärtusi, mida IObserver (selles <T>tegevuses) konsoolile prindib järgmisel pildil. See aitab meil hõlpsasti võrrelda ülejäänud õdesid-vendi ja variante.
Esimene rida tähistab avaldatud väärtust ja teine rida IObserveri poolt vastu võetud väärtust. Lisaks oleme lisanud rea, mis näitab, millal vaatleja voogu täitmise ajal tellib. See joon on kujutatud vertikaalse punktijoonena.
Ülaltoodud koodis märkasime, et vaatleja tellis andmevoo enne esimese väärtuse avaldamist. Pildil on näha tellija rida, mis on paigutatud esimese elemendi ette. Nagu väljundliinilt näha, ei mõjuta see väljundit (praegu).
Aga mis siis, kui vaatleja tellib andmeid alles pärast mõne väärtuse avaldamist? Kas see mõjutab vaatlejate poolt saadud andmeid? Enne väljundi vaatamist kirjutame kõigepealt sama koodi.
Ülaltoodud koodis võime täheldada, et vaatleja liitub andmevoo alles pärast kahe väärtuse (1 ja 2) avaldamist. Nagu arvata võib, põhjustab see, et vaatlejad ei saa enne tellimusmeetodi kutsumist avaldatud andmeid. Nagu alloleval joonisel näidatud.
Mis siis, kui tahad lugeda kõiki avaldatud väärtusi, isegi kui vaatleja tellib hiljem? Siin tuleb mängu ReplaySubject<T>.
KordusTeema<T>
ReplaySubject<T> salvestab väärtused vahemällu ja mängib neid hilisematele tellijatele uuesti. See on kasulik võistlustingimuste vältimiseks. Muudame eelmise koodi, kasutades<T> ReplaySubject'i ja vaatame, kuidas see mõjutab seda, mida vaatleja saab.
Nagu ülaltoodud koodist näidatud, on<T> <T>koodis peaaegu muudatusi, välja arvatud see, et kasutame nüüd ReplaySubject'i subjekti asemel. Järgmine diagramm illustreerib vaatleja poolt saadud andmete mõju.
Nagu pildil näidatud, mängitakse vahemällu salvestatud väärtus nüüd tellijale uuesti ka siis, kui tellija tellib hiljem. Muidugi tuleb see kasulik funktsioon hinnaga. See rakendus salvestab vahemällu kõik tellija avaldatud väärtused, mis võib põhjustada halbu mäluprobleeme, kui andmemaht on oluliselt suurem.
Kuid ReplaySubjectil on selle<T> probleemi lahendamiseks rohkem kui üks võimalus. Selle näite huvides vaatame kahte näidet, mis kasutavad suuruse ja ajapiiranguid vahemällu salvestatud väärtuse piiramiseks.
Esimesel juhul kasutame vahemälu suurust, et piirata vahemälu väärtust. <T>ReplaySubjecti konstruktor pakub ülekoormust, mis aktsepteerib täisarvu, mis esindab vahemälupuhvri suurust (maksimaalne elementide arv). Meie näites muudame koodi nii, et vahemälu suurus on piiratud väärtusega 1.
Pane tähele, kuidas <T>kasutame ReplaySubjecti konstruktori ülekoormust, et anda vahemälu suurus 1. See piirab vahemällu salvestamist ja tagab, et vahemällu salvestatakse ja asendatakse uue elemendiga kohe pärast avaldamist. Muudatuse mõju on toodud allpool.
Teine viis vahemällu salvestamise piiramiseks on piirata vahemällu salvestatud eseme aega ehk teisisõnu anda vahemällu salvestatud esemele aegumisaeg.
Kirjutame koodi, et seda näidet illustreerida.
Sarnaselt eelmisele koodile kasutame<T> ReplaySubject konstruktori ülekoormust, et määrata vahemälus olevate esemete aegumisaeg. Oma seisukoha tõestamiseks kehtestasime väärtuste avaldamise vahele viivituse.
Kuna vaatleja tellimuse esitamiseks kulub täis 1200 ms, eemaldatakse vahemälust kõik elemendid, mis ületavad 1000 ms aegumisaja. Selles näites eemaldatakse väärtus 1 vahemälust ja seda ei mängita hilistele tellijatele uuesti. Nagu alloleval joonisel näidatud.
<T>ReplaySubjecti jaoks on ka teisi ülekoormusi, mis pakuvad rohkem paindlikkust ja täpsustavad vahemällu salvestatud väärtusi, kuid näiteks jätame juba käsitletud kaks näidet.
KäitumineSubjekt<T>
BehaviourSubject <T>on väga sarnane<T> ReplaySubjectile, kuna aitab väärtusi vahemällu salvestada. Kuid on märkimisväärne erinevus. BehaviourSubject<T> vahemällu salvestab ainult viimase avaldatud väärtuse. Enne kui edasi süveneme, kirjutame natuke koodi.
Kui BehaviorSubject<T> salvestab vahemällu ainult ühe väärtuse (mis on viimati teada), siis kuidas erineb see suurusega 1 ReplaySubjectist<T>? Järgmine diagramm peegeldab selgelt ülaltoodud koodi olukorda.
Kuid see ei vasta päris tõele. Siin on kaks olulist erinevust, mida mõista. Esimene on vaikimisi olemasolu. Pane tähele, et ülaltoodud koodis <T>anname BehaviourSubjecti konstruktoris vaikimisi väärtuse 0. Kui vahemälus ühtegi väärtust ei eksisteeri (või teisisõnu, enne vaatleja tellimist andmeid ei avaldatud), tagastatakse vaikimisi väärtus. See erineb ReplaySubjectist, mille suurus on 1<T>, millel pole mingit väärtust. Järgmine kood ja visuaalne kujutis jadast demonstreerivad seda käitumist.
Teine erinevus on see, kuidas BehaviorSubject<T> ja ReplaySubject<T> käituvad, kui tellitakse lõpetatud järjestus. Kui tellite pärast tellimuse lõpetamist, ei <T> ole BehaviorSubjectil mingit väärtust, nagu allolevas koodis näidatud.
Tellijatele on garanteeritud, et nad ei saa mingit väärtust, sest tellimused tekivad pärast lõpetamist.
Kuid <T>see kehtib ReplaySubjecti puhul. Puudub garantii, et vaatleja ei saa ühtegi väärtust, nagu allolevas koodis näidatud.
Nagu ülaltoodud koodis näidatud, on vahemälu suurus 1 ja isegi kui tellimus kutsutakse pärast kõne lõpetamist, jääb vahemälu alles (kuni aegumistingimus on täidetud), seega võetakse sel juhul vastu viimane avaldatud väärtus.
AsünkroonSubjekt<T>
AsyncSubject <T>on Subjekti viimane vend, mida selles artiklis <T>käsitleme, ning see on väga sarnane eelnevatele kahele (ReplaySubject ja BehaviourSubject) selle poolest, et salvestab ka tulemusi. Aga jällegi on oluline erinevus. AsyncSubject avaldab viimase vahemällu salvestatud väärtuse ainult siis, kui järjestus on märgitud <T> lõpetatuks (vahemällu salvestab ainult ühe väärtuse, viimase väärtuse).
Vaatleme järgmist koodi.
See genereerib vaatlejale väärtuse, et jada on märgitud viimaseks enne lõpetamist avaldatud väärtuseks – väärtus 4. Nagu alloleval joonisel näidatud.
Aga mis juhtub, kui jätame vahele kutse, mis märgib järjestuse lõpetatuks? Kommenteerime lause ja proovime uuesti.
See ei genereeri vaatlejale andmeid, sest AsyncSubject<T> avaldab tulemused alles pärast järjestuse lõpetamist märgitud.
See on märkimisväärne erinevus, mida iga AsyncSubjecti kasutaja <T>peaks meeles pidama.
Järeldus
See artikkel <T>näitab erinevusi Subjekti erinevate õdede-vendade ja mõningate selle variatsioonide vahel. Sageli on kasulik olla teadlik neist peentest erinevustest, sest need võivad käituda teistmoodi kui sa arvasid, kui sa seda ei märka.
Originaallink:Hüperlingi sisselogimine on nähtav.
|
Eelmine:.NET/C# kontrollib, kas TCP port on saadavalJärgmine:NSIS (1) Tee lihtne paigaldaja
|
Üürileandja|
Postitatud 27.01.2024 12:19:47
|
