Die .Net Reactive Extension bietet Entwicklern eine Reihe von Funktionen, um ein reaktives Programmiermodell für .Net-Entwickler zu implementieren, um die Ereignisbehandlung durch deklarative Aktionen einfacher und ausdrucksstärker zu gestalten. Während die wichtigsten Eckpfeiler des reaktiven Skalierens die IObserver- und IObservable-Schnittstellen sind, muss man als Entwickler diese Schnittstellen oft nicht selbst implementieren. Die Bibliothek unterstützt den eingebauten Typ Subject<T>, der Schnittstellen implementiert und viele Funktionen unterstützt.
Themen bilden die Grundlage für die verschiedenen in der Bibliothek verfügbaren Themen, und es gibt weitere Themen – ReplaySubject<T>, BehaviorSubject<T> und AsyncSubject<T>. Es ist hilfreich, die wesentlichen Unterschiede zwischen ihnen zu verstehen und wie man sie nutzt, um die Bibliothek besser zu nutzen.
In diesem Artikel vergleichen wir Subjekt<T> und sein Geschwisterkind und versuchen, die Unterschiede in ihrem Verhalten zu veranschaulichen.
Betreff<T>
Wie bereits erwähnt,<T> bildet Subject die Grundlage für die verfügbaren Themen und bietet eine einfache Möglichkeit, die Bibliothek zu nutzen, ohne die IObservable<T>- und IObserver-Schnittstellen selbst implementieren zu müssen<T>. Eine einfache Demonstration des Thementyps ist unten dargestellt.
Im obigen Code haben wir eine <T>Instanz von Subject erstellt, und da sie<T> IObserver und IObserverable implementiert<T>, verwenden wir dieselbe Instanz, um den Wert auf IObserver zu abonnieren und zu veröffentlichen. Ein weiterer wichtiger Punkt ist, wie wir die Überlastung der Subscribe-Methode nutzen, um Aktionen als Eingabe zu akzeptieren. Dies geschieht für jeden veröffentlichten Wert, in diesem Fall wird die Zahl auf die Konsole gedruckt.
Versuchen wir, die veröffentlichten Werte und die Werte anzuzeigen, die IObserver (in dieser Aktion<T>) in der Konsole im folgenden Bild ausdruckt. Das wird uns helfen, die übrigen Geschwister und Varianten leicht zu vergleichen.
Die erste Zeile stellt den veröffentlichten Wert dar, und die zweite Zeile den vom IObserver empfangenen Wert. Zusätzlich haben wir eine Zeile hinzugefügt, die anzeigt, an welchem Zeitpunkt der Beobachter während der Ausführung den Stream abonniert. Diese Linie wird durch eine vertikale gestrichelte Linie dargestellt.
Im obigen Code haben wir festgestellt, dass der Beobachter vor der Veröffentlichung des ersten Werts den Datenstrom abonniert hat. Das Bild zeigt die Subscriber-Zeile vor dem ersten Element. Wie man an der Ausgangsleitung sehen kann, hat dies keine Auswirkungen auf den Ausgang (zu diesem Zeitpunkt).
Aber was, wenn der Beobachter die Daten erst abhebt, nachdem einige Werte bereits veröffentlicht wurden? Hat das Auswirkungen auf die von Beobachtern erhaltenen Daten? Bevor wir uns die Ausgabe ansehen, schreiben wir zuerst denselben Code.
Im obigen Code können wir beobachten, dass der Beobachter den Datenstrom erst abhebt, nachdem zwei Werte (1 und 2) veröffentlicht wurden. Wie zu erwarten, führt dies dazu, dass Beobachter vor dem Aufruf der Abonnementmethode keine veröffentlichten Daten erhalten. Wie in der untenstehenden Abbildung gezeigt.
Was, wenn Sie alle veröffentlichten Werte lesen möchten, auch wenn der Beobachter spät abonniert? Hier kommt ReplaySubject<T> ins Spiel.
ReplaySubject<T>
ReplaySubject<T> speichert Werte und spielt sie für spätere Abonnenten erneut ab. Das ist nützlich, um Rennbedingungen zu vermeiden. Lasst uns den vorherigen Code ändern, um ReplaySubject zu verwenden,<T> und sehen, wie er beeinflusst, was der Beobachter erhält.
Wie im obigen Code gezeigt, gibt es<T> <T>kaum Änderungen im Code, außer dass wir jetzt ReplaySubject statt subject verwenden. Das folgende Diagramm veranschaulicht die Auswirkungen auf die vom Beobachter empfangenen Daten.
Wie auf dem Bild gezeigt, wird der zwischengespeicherte Wert nun dem Abonnenten wiedergegeben, selbst wenn dieser später abonniert. Natürlich hat dieses nützliche Feature seinen Preis. Diese Implementierung speichert jeden vom Abonnenten veröffentlichten Wert, was zu schlechten Speicherproblemen führen kann, wenn die Datenmenge deutlich größer ist.
ReplaySubject<T> hat jedoch mehr als eine Möglichkeit, dieses Problem zu lösen. Für dieses Beispiel betrachten wir zwei Beispiele, die Größen- und Zeitbeschränkungen verwenden, um den zwischengespeicherten Wert zu begrenzen.
Im ersten Fall verwenden wir die Größe des Caches, um den Wert des Caches zu begrenzen. <T>Der Konstruktor von ReplaySubject liefert eine Überlastung, die eine ganze Zahl akzeptiert, die die Größe des Cache-Puffers (maximale Elementanzahl) darstellt. In unserem Beispiel ändern wir den Code, um die Cache-Größe auf 1 zu begrenzen.
Beachten Sie, wie wir <T>den Konstruktor-Überload von ReplaySubject verwenden, um die Größe des Caches als 1 anzugeben. Dies begrenzt das Caching und stellt sicher, dass nur ein Element zwischengespeichert und sofort nach der Veröffentlichung durch ein neues ersetzt wird. Die Auswirkungen der Änderung sind unten dargestellt.
Eine weitere Möglichkeit, das Caching zu begrenzen, besteht darin, die Zeit des zwischengespeicherten Objekts zu begrenzen oder anders gesagt, eine Ablaufzeit für das zwischengespeicherte Element bereitzustellen.
Schreiben wir Code, um dieses Beispiel zu veranschaulichen.
Ähnlich wie beim vorherigen Code verwenden wir<T> die Überladung des ReplaySubject-Konstruktors, um die Verfallszeit von Elementen im Cache anzugeben. Um unseren Fall zu untermauern, haben wir eine Verzögerung zwischen der Freigabe der Werte eingeführt.
Da es volle 1200 ms dauert, bevor der Beobachter abonniert, werden alle Elemente, die die Ablaufzeit von 1000 ms überschreiten, aus dem Cache entfernt. In diesem Beispiel wird der Wert 1 aus dem Cache entfernt und nicht an späte Abonnenten abgespielt. Wie in der untenstehenden Abbildung gezeigt.
Es <T>gibt weitere Overloads für ReplaySubject, die mehr Flexibilität bieten und die zwischengespeicherten Werte feinjustieren, aber als Beispiele behalten wir die beiden oben bereits behandelten Beispiele.
VerhaltenSubjekt<T>
BehaviourSubject <T>ist ReplaySubject sehr ähnlich,<T> da es Werte beim Cachen unterstützt. Aber es gibt einen erheblichen Unterschied. BehaviourSubject<T> speichert nur den zuletzt veröffentlichten Wert. Bevor wir weiter darauf eingehen, schreiben wir etwas Code.
Wenn das BehaviorSubject<T> nur einen einzigen Wert (der zuletzt bekannt ist) zwischenspeichert, wie unterscheidet sich das dann von einem ReplaySubject der Größe 1<T>? Das folgende Diagramm spiegelt die Situation des obigen Codes klar wider.
Das ist jedoch nicht ganz richtig. Es gibt hier zwei wichtige Unterschiede, die man verstehen sollte. Das erste ist das Vorhandensein von Zahlungsausfallen. Beachten Sie, dass wir im obigen Code <T>den Wert 0 als Standard im Konstruktor von BehaviourSubject angeben. Wenn kein Wert im Cache vorhanden ist (oder anders gesagt, keine Daten vor dem Abonnement des Beobachters veröffentlicht wurden), wird der Standardwert zurückgegeben. Das unterscheidet sich von ReplaySubject, das eine Größe von 1 hat<T>, aber keinen Wert hat. Der folgende Code und eine visuelle Darstellung der Sequenz demonstrieren dieses Verhalten.
Der zweite Unterschied ist, wie sich BehaviorSubject<T> und ReplaySubject verhalten,<T> wenn sie eine abgeschlossene Sequenz abonnieren. Wenn du nach Abschluss abonnierst, hat das BehaviorSubject <T> keinen Wert, wie im untenstehenden Code gezeigt.
Abonnenten erhalten garantiert keinen Wert, da die Abonnements erst nach Abschluss erfolgen.
Dies <T>ist jedoch bei ReplaySubject der Fall. Es gibt keine Garantie, dass der Beobachter keine Werte erhält, wie im untenstehenden Code gezeigt.
Wie im obigen Code gezeigt, ist der Cache 1 groß, und selbst wenn das Abonnement nach Abschluss des Aufrufs aufgerufen wird, bleibt der Cache erhalten (bis die Ablaufbedingung erfüllt ist), sodass in diesem Fall der zuletzt veröffentlichte Wert empfangen wird.
AsyncSubject<T>
AsyncSubject <T>ist das letzte Geschwister des Subject, das wir in diesem Artikel behandeln werden<T>, und es ist den beiden vorherigen (ReplaySubject und BehaviourSubject) sehr ähnlich, da es auch Ergebnisse zwischenspeichert. Aber auch hier gibt es einen deutlichen Unterschied. AsyncSubject veröffentlicht den zuletzt zwischengespeicherten Wert nur, wenn die Sequenz als vollständig markiert ist <T> (es cacht nur einen Wert, den letzten Wert).
Betrachten Sie folgenden Code.
Dies erzeugt einen Wert für den Beobachter, dass die Sequenz als der letzte vor Abschluss veröffentlichte Wert markiert ist – Wert 4. Wie in der untenstehenden Abbildung gezeigt.
Aber was passiert, wenn wir den Aufruf überspringen, der die Sequenz als abgeschlossen markiert? Lass uns die Zeile kommentieren und es noch einmal versuchen.
Dies erzeugt keine Daten für den Beobachter, da AsyncSubject<T> Ergebnisse erst veröffentlicht, nachdem die Sequenz als abgeschlossen markiert wurde.
Das ist ein bedeutender Unterschied, den jeder, der AsyncSubject nutzt<T>, im Hinterkopf behalten sollte.
Schlussfolgerung
Dieser Artikel zeigt <T>die Unterschiede zwischen den verschiedenen Geschwistern von Subjekt und einige seiner Varianten. Es ist oft hilfreich, sich dieser subtilen Unterschiede bewusst zu sein, da sie ein anderes Verhalten zeigen können, als man erwartet hat, wenn man es nicht bemerkt.
Originallink:Der Hyperlink-Login ist sichtbar.
|
Veröffentlicht am 27.01.2024 12:17:19
|
|
|
|
Vermieter|
Veröffentlicht am 27.01.2024 12:19:47
|
