.Net reaktīvais paplašinājums nodrošina izstrādātājiem funkciju kopumu, lai ieviestu reaktīvo programmēšanas modeli .Net izstrādātājiem, lai padarītu notikumu apstrādi vienkāršāku un izteiksmīgāku, izmantojot deklaratīvas darbības. Lai gan galvenie reaktīvās mērogošanas stūrakmeņi ir IObserver un IObservable saskarnes, jums kā izstrādātājam bieži vien šīs saskarnes nav jāievieš pašam. Bibliotēka atbalsta iebūvēto tipu Subject<T>, kas īsteno saskarnes un atbalsta daudzas funkcijas.
Dizaini ir pamats dažādām bibliotēkā pieejamajām tēmām, un ir arī citas tēmas - ReplaySubject<T>, BehaviorSubject<T> un AsyncSubject<T>. Ir lietderīgi saprast būtiskās atšķirības starp tām un to, kā tās izmantot, lai labāk izmantotu bibliotēku.
Šajā rakstā mēs salīdzināsim priekšmetu<T> un tā brāli, cenšoties ilustrēt atšķirības starp viņu uzvedību.
Priekšmets<T>
Kā minēts iepriekš, tēma<T> ir pieejamo tēmu pamats, nodrošinot vienkāršu bibliotēkas lietošanas veidu, neieviešot IObservable<T> un IObserver<T> saskarnes. Vienkārša dizaina tipa demonstrācija ir parādīta zemāk.
Iepriekš minētajā kodā mēs izveidojām <T>Subject instanci, un, tā kā tā ievieš<T> IObserver un IObserverable<T>, izmantojiet to pašu instanci, lai abonētu un publicētu vērtību IObserver. Vēl viens svarīgs punkts, kas jāatzīmē, ir tas, kā mēs izmantojam abonēšanas metodes pārslodzi, lai pieņemtu darbības kā ievadi. Tas tiks darīts katrai publicētajai vērtībai, šajā gadījumā izdrukājot numuru konsolē.
Mēģināsim parādīt publicētās vērtības un vērtības, ko IObserver (šajā darbībā<T>) drukā konsolē nākamajā attēlā. Tas palīdzēs mums viegli salīdzināt atlikušos brāļus un māsas un variantus.
Pirmā rindiņa apzīmē publicēto vērtību, bet otrā rindiņa norāda vērtību, ko saņēmis IObserver. Turklāt mēs esam pievienojuši līniju, lai norādītu, kurā brīdī novērotājs abonē plūsmu izpildes laikā. Šo līniju attēlo vertikāla punktēta līnija.
Iepriekš minētajā kodā mēs pamanījām, ka novērotājs pirms pirmās vērtības publicēšanas abonēja datu plūsmu. Attēlā redzama abonenta rinda, kas novietota pirms pirmā elementa. Kā redzat no izejas līnijas, tas neietekmē izvadi (šajā brīdī).
Bet ko darīt, ja novērotājs abonē datus tikai pēc tam, kad dažas vērtības jau ir publicētas? Vai tas ietekmē novērotāju saņemtos datus? Pirms aplūkot izvadi, vispirms uzrakstīsim to pašu kodu.
Iepriekš minētajā kodā mēs varam novērot, ka novērotājs abonē datu plūsmu tikai pēc divu vērtību (1 un 2) publicēšanas. Kā varētu sagaidīt, tas liks novērotājiem nesaņemt datus, kas publicēti pirms abonēšanas metodes izsaukšanas. Kā parādīts zemāk redzamajā attēlā.
Ko darīt, ja vēlaties izlasīt visas publicētās vērtības, pat ja novērotājs abonē novēloti? Šeit spēlē ReplaySubject<T>.
Atskaņot tēmu<T>
ReplaySubject<T> kešatmiņā saglabā vērtības un atskaņo tās vēlākiem abonentiem. Tas ir noderīgi, lai izvairītos no sacensību apstākļiem. Mainīsim iepriekšējo kodu, lai izmantotu ReplaySubject<T> un redzētu, kā tas ietekmē novērotāja saņemto.
Kā parādīts iepriekš minētajā kodā,<T> <T>kodā gandrīz nav nekādu izmaiņu, izņemot to, ka mēs tagad izmantojam ReplaySubject tēmas vietā. Nākamajā diagrammā parādīta ietekme uz novērotāja saņemtajiem datiem.
Kā parādīts attēlā, kešatmiņā saglabātā vērtība tagad tiek atskaņota abonentam pat tad, ja abonents abonē vēlāk. Protams, šai noderīgajai funkcijai ir sava cena. Šī ieviešana kešatmiņā saglabās visas abonenta publicētās vērtības, kas var izraisīt sliktas atmiņas problēmas, ja datu apjoms ir ievērojami lielāks.
Tomēr ReplaySubject<T> ir vairāk nekā viens veids, kā atrisināt šo problēmu. Šajā piemērā apskatīsim divus piemērus, kuros tiks izmantoti lieluma un laika ierobežojumi, lai ierobežotu kešatmiņā saglabāto vērtību.
Kā pirmo gadījumu mēs izmantosim kešatmiņas lielumu, lai ierobežotu kešatmiņas vērtību. <T>ReplaySubject konstruktors nodrošina pārslodzi, kas pieņem veselu skaitli, kas atspoguļo kešatmiņas bufera lielumu (maksimālais elementu skaits). Mūsu piemērā mainīsim kodu, lai ierobežotu kešatmiņas lielumu līdz 1.
Ņemiet vērā, kā mēs izmantojam <T>ReplaySubject konstruktora pārslodzi, lai nodrošinātu kešatmiņas lielumu kā 1. Tas ierobežo kešatmiņu un nodrošina, ka tikai viens elements tiek saglabāts kešatmiņā un aizstāts ar jaunu elementu, tiklīdz tas tiek publicēts. Izmaiņu ietekme ir parādīta zemāk.
Vēl viens veids, kā ierobežot kešatmiņu, ir ierobežot kešatmiņas vienuma laiku vai, citiem vārdiem sakot, nodrošināt kešatmiņas vienuma derīguma termiņu.
Uzrakstīsim kodu, lai ilustrētu šo piemēru.
Līdzīgi kā iepriekšējā kodā, mēs izmantojam<T> ReplaySubject konstruktora pārslodzi, lai norādītu kešatmiņā esošo vienumu derīguma termiņu. Lai parādītu savu lietu, mēs ieviesām aizkavēšanos starp vērtību izlaišanu.
Tā kā novērotājs abonē veselus 1200 ms, visi elementi, kas pārsniedz 1000 ms derīguma termiņu, tiks noņemti no kešatmiņas. Šajā piemērā vērtība 1 tiks noņemta no kešatmiņas un netiks atskaņota vēlu abonentiem. Kā parādīts zemāk redzamajā attēlā.
<T>ReplaySubject ir arī citas pārslodzes, kas nodrošina lielāku elastību un precīzi noregulē kešatmiņā saglabātās vērtības, bet, piemēram, mēs saglabāsim divus piemērus, kas jau aprakstīti iepriekš.
UzvedībaTēma<T>
BehaviorSubject <T>ir ļoti līdzīgs ReplaySubject<T>, jo tas palīdz kešatmiņā saglabāt vērtības. Bet ir būtiska atšķirība. BehaviorSubject<T> kešatmiņā saglabā tikai pēdējo publicēto vērtību. Pirms mēs iedziļināmies šajā tālāk, uzrakstīsim kodu.
Ja BehaviorSubject<T> kešatmiņā saglabā tikai vienu vērtību (kas ir pēdējā zināmā), kā tā atšķiras no ReplaySubject ar izmēru 1<T>? Šī diagramma skaidri atspoguļo iepriekš minētā koda situāciju.
Tomēr tas nav pilnīgi taisnība. Šeit ir jāsaprot divas svarīgas atšķirības. Pirmais ir noklusējuma klātbūtne. Ņemiet vērā, ka iepriekš minētajā kodā mēs <T>norādām vērtību 0 kā noklusējumu BehaviorSubject konstruktorā. Ja kešatmiņā nav vērtības (vai, citiem vārdiem sakot, dati nav publicēti pirms novērotāja abonēšanas), tiks atgriezta noklusējuma vērtība. Tas atšķiras no ReplaySubject, kura izmērs ir 1<T>, kam nav nekādas vērtības. Tālāk norādītais kods un secības vizuālais attēlojums parāda šo darbību.
Otra atšķirība ir tā, kā BehaviorSubject<T> un ReplaySubject<T> uzvedas, abonējot pabeigtu secību. Abonējot pēc pabeigšanas, BehaviorSubject <T> nebūs vērtības, kā parādīts zemāk esošajā kodā.
Abonentiem tiek garantēts, ka viņi nesaņems nekādu vērtību, jo abonementi notiek pēc pabeigšanas.
Tomēr <T>tas attiecas uz ReplaySubject . Nav garantijas, ka novērotājs nesaņems nekādas vērtības, kā parādīts zemāk esošajā kodā.
Kā parādīts iepriekš minētajā kodā, kešatmiņa ir 1 liela, un pat tad, ja abonements tiek izsaukts pēc zvana pabeigšanas, kešatmiņa paliks (līdz derīguma termiņa beigām), tāpēc šajā gadījumā tiks saņemta pēdējā publicētā vērtība.
Asinhronā tēma<T>
AsyncSubject <T>ir pēdējais tēmas brālis, kuru mēs izpētīsim šajā rakstā<T>, un tas ir ļoti līdzīgs iepriekšējiem diviem (ReplaySubject un BehaviorSubject), jo tas arī kešatmiņā saglabā rezultātus. Bet atkal ir būtiska atšķirība. AsyncSubject publicē pēdējo kešatmiņā saglabāto vērtību tikai tad, ja secība ir atzīmēta kā pabeigta <T> (kešatmiņā tiek saglabāta tikai viena vērtība, pēdējā vērtība).
Apsveriet šādu kodu.
Tas novērotājam radīs vērtību, ka secība ir atzīmēta kā pēdējā vērtība, kas publicēta pirms pabeigšanas - vērtība 4. Kā parādīts zemāk redzamajā attēlā.
Bet kas notiek, ja mēs izlaižam zvanu, kas atzīmē secību kā pabeigtu? Komentēsim līniju un mēģināsim vēlreiz.
Tas neģenerē nekādus datus novērotājam, jo AsyncSubject<T> publicē rezultātus tikai pēc tam, kad secība ir atzīmēta kā pabeigta.
Šī ir būtiska atšķirība, kas jāpatur prātā ikvienam, kas izmanto AsyncSubject<T>.
Secinājums
Šis <T>raksts parāda atšķirības starp dažādiem Subject brāļiem un māsām un dažām tā variācijām. Bieži vien ir lietderīgi apzināties šīs smalkās atšķirības, jo tās var izrādīt atšķirīgu uzvedību, nekā jūs gaidījāt, ja jūs to neapzināties.
Oriģinālā saite:Hipersaites pieteikšanās ir redzama.
|
Publicēts 27.01.2024 12:17:19
|
|
|
|
Saimnieks|
Publicēts 27.01.2024 12:19:47
|
