Vorteile .NETTO-Rx über die klassische Ereignisse?

Können Sie IObservable als ein Ereignis, ersetzen von code, der Ereignisse verfügbar, die mit den Eigenschaften von Typ IObservable, aber das ist nicht wirklich der Punkt.

Gibt es zwei wichtige Dinge zu verstehen, über IObservable:

1. Es vereint zwei Konzepte, dass wir nicht wissen, wie zu vereinheitlichen, bevor: asynchrone Operationen (die in der Regel einen einzelnen Wert zurückgeben) und Aktionen (die in der Regel gehen auf ewig).

2. Es ist composable. Im Gegensatz zu CLR-Ereignisse, IAsyncResult, oder INotifyCollectionChanged es uns ermöglicht, zu bauen, die bestimmte Ereignisse aus der Allgemeinen Ereignisse und asynchrone Operationen.

Hier ist ein Beispiel ich lief in bei der Arbeit nur am Nachmittag.

In Silverlight gibt es einige Effekte, die Sie anwenden können, um ein Bild-Steuerelement, das nicht angewendet werden kann, um eine normale Kontrolle. Um diese Einschränkungen zu umgehen, wenn ein Steuerelement den Inhalt geändert wird, ich kann warten, für seine visuelle Darstellung aktualisiert werden, und nehmen Sie einen screenshot davon. Dann will ich verstecken Ihre visuelle Darstellung, ersetzen Sie es mit der snapshot, und wenden Sie die visuellen Effekte das Bild. Jetzt kann ich anwenden von Bild-Effekten zu Steuern (vorausgesetzt, es ist nicht interaktiv).

Dieses Programm wäre trivial, aber für die Tatsache, dass es sein muss asynchron. Ich muss warten, bis zwei aufeinanderfolgende asynchrone Vorgänge abgeschlossen sind, bevor ich mich bewerben kann Effekte auf das Bild:

1. Die Kontrolle der Inhalte geändert
2. Die Kontrolle Erscheinungsbild aktualisiert

Hier ist, wie ich dieses problem beheben, indem Rx:

//A content control is a control that displays content.  That content can be
//anything at all like a string or another control.  Every content control contains
//another control: a ContentPresenter.  The ContentPresenter's job is to generate
//a visual representation of the Content property. For example, if the Content property
//of the ContentControl is a string, the ContentPresenter creates a TextBlock and inserts
//the string into it.  On the other hand if the Content property is another control the 
//ContentPresenter just inserts it into the visual tree directly.
public class MyContentControl : ContentControl
{
   //A subject implements both IObservable and IObserver.  When IObserver methods
   //are called, it forwards those calls to all of its listeners.
   //As a result it has roughly the same semantics as an event that we can "raise."
   private Subject<object> contentChanged = new Subject<object>();

   //This is a reference to the ContentPresenter in the ContentControl's template
   private ContentPresenter contentPresenter; 

   //This is a reference to the Image control within ContentControl's template.  It is displayed on top of the ContentPresenter and has a cool blur effect applied to it.
   private Image contentImageControl; 

   public MyContentControl()
   {
      //Using Rx we can create specific events from general events.
      //In this case I want to create a specific event ("contentImageChanged") which
      //gives me exactly the data I need to respond and update the UI.
      var contentImageChanged = 
         //get the content from the content changed event
         from content in contentChanged
         where content != null
         //Wait for the ContentPresenter's visual representation to update.
         //ContentPresenter is data bound to the Content property, so it will
         //update momentarily.
         from _ in contentPresenter.GetLayoutUpdated().Take(1)
         select new WritableBitmap(contentPresenter, new TranslateTransform());

      contentImageChanged.Subscribe(
         contentImage => 
         {
            //Hide the content presenter now that we've taken a screen shot              
            contentPresenter.Visibility = Visibility.Collapsed; 

            //Set the image source of the image control to the snapshot
            contentImageControl.ImageSource = contentImage;
         });
   }

   //This method is invoked when the Content property is changed.
   protected override OnContentChanged(object oldContent, object newContent)
   {
      //show the content presenter before taking screenshot
      contentPresenter.Visibility = Visibility.Visible;  

      //raise the content changed "event"
      contentChanged.OnNext(newContent);   

      base.OnContentChanged(oldContent, newContent);
   }
}

Diesem Beispiel ist besonders einfach, da es nur zwei aufeinander folgenden Operationen zur Folge. Sogar in diesem einfachen Beispiel wenn wir sehen, dass der Rx-Wert hinzufügt. Ohne ihn hätte ich haben verwendet state-Variablen zu gewährleisten, wurden die Ereignisse auslösen in einer bestimmten Reihenfolge. Ich würde auch habe zu schreiben hatte einige ziemlich hässlichen code ausdrücklich zu trennen von dem LayoutUpdated Ereignis.

Wenn Sie die Programmierung mit Rx der trick ist, zu denken, "Welche Veranstaltung will ich meinen Rahmen?" und dann gehen Sie ihn erstellen. Wir sind ausgebildet, um zu denken über die Ereignisse als einfache input-driven Dinge ("mouseover", "Mausklick", "keyup", etc). Aber es gibt keinen Grund, die Ereignisse nicht sehr Komplex und speziell auf Ihre app ("GoogleMsdnMashupStockDataArrived", "DragStarting" und "ImageContentChanged"). Wenn Sie die Struktur Ihrer Programme auf diese Weise (erzeugen genau die Veranstaltung, die ich brauche und dann darauf zu reagieren, indem Staatliche) werden Sie feststellen, dass Sie weniger Staat bugs, werden mehr bestellt, und sind insgesamt mehr selbst beschreibt.

Habe? 🙂

Es ist nur eine Erweiterung, um die Ereignis-basierte Programmierung-Modell. Sie schaffen etwas, was implements IObserver, und im Grunde sagst du "hier ist, was ich will, geschehen wird, wenn etwas in der Sammlung-änderungen". So, es ist nur eine Standardisierung, was wir alle gewartet haben zu tun mit Ereignissen.

Üben Sie Druck aus, wie es ist eine große Kehrtwende im Vergleich mit der IEnumerable-Muster. IEnumerable ist "ziehen", in der Erwägung, dass IObservable ist "push".

Der einzige Vorteil, den ich sehe über straight-events ist, dass es eine standardisierte Schnittstelle. Ich sehe eine große überlappung mit ObservableCollection hier aber (und INotifyCollectionChanged). Vielleicht sind Sie versuchen zu verabschieden, das PERL-motto mit .NET: "es gibt mehr als einen Weg, es zu tun".