Ich hoffe, dass es angebracht wäre, Stephen Toub, MSFT (*) aus seinem zitieren:

ParallelExtensionsExtras Tour - # 2 - Task.ToObservable MSDN-Blog-Artikel:

  

Wie sich herausstellt, während Task<TResult> nicht zur Zeit implementieren IObservable<T> , es ist eigentlich eine ziemlich gute Passform zu tun. Ein Observable repräsentiert eine beliebige Anzahl von Werten, die entweder durch ein Ende des Streams oder durch eine Ausnahme beendet werden. A Task<TResult> paßt diese Beschreibung: Es schließt entweder mit einem einzelnen Wert oder mit einer Ausnahme. Zwar ist es möglich, dass eine zukünftige Version des .NET Framework sieht Task<TResult> implementieren IObservable<T> , können wir das entsprechende Verhalten jetzt erhalten, indem sie als eine Erweiterungsmethode für Task<TResult> förder; Tatsächlich enthält Rx genau eine solche Erweiterungsmethode, ebenso wie ParallelExtensionsExtras

(*) nicht sicher, was "FT" bedeutet, mit der Ausnahme, dass MSFT NASDAQ ist Aktiensymbol MS Bedeutung, aber " MS "in" MSFT "bedeutet sicher Microsoft

Dies wurde sehr gut vom Rx-Team mit ihr 2.0 Beta-Blogpost . Es ist ein massiver Beitrag, obwohl es dort jede Menge toller Informationen gibt.

preemptive tl; dr = IObservable ist für Folgen zukünftiger Ergebnisse, Aufgabe ist für ein einzelnes zukünftiges Ergebnis

Das Diagramm, von dem ich denke, dass es die beste Aufgabe ist, die Beziehung zu erklären, ist in diesem Beitrag, aber leider ziemlich weit unten (und wie ich schon sagte, es ist ein sehr großer Beitrag:)

Während der gesamte Beitrag lesenswert ist (IMHO), beginnt der relevante Text darüber, wie Rx / Task / async / alle zusammenpassen, bei der Überschrift "Rx v2.0 und .NET 4.5" async "/" abwarten "- eine bessere zusammen Geschichte "

Ich kann nur raten, aber ich denke, es gibt einige gute Gründe:

1. Task<T> und IObservable<T> haben eigentlich nicht das gleiche zugrundeliegende Konzept. Ja, beide sind asynchron, aber das ist so ziemlich alles, wo die Gemeinsamkeit endet. Der große Unterschied zwischen den beiden ist, dass Task<T> immer einen einzelnen Wert hat, IObservable<T> kann so viele Werte haben (oder so wenig wie Null), wie es will.

   Wenn Task<T> implementiert IObservable<T> ist, wäre es ähnlich, als würde jedes T in .Net IEnumerable<T> implementiert, was ein einzelnes Ergebnis, das Objekt selbst, zurückgibt.

2. Es ist trivial, Task<T> in IObservable<T> zu konvertieren. Entweder mit der ToObservable() Erweiterungsmethode von Rx, oder von selbst schreiben . Dies macht das, wonach du verlangst, viel weniger notwendig.

Der Grund dafür ist, dass, während sich der Task<T> -Typ im .NET Framework befindet, die Reactive Extensions (Rx) und IObservable<T> nicht sind. Die System.Reactive -Assembly hat System.Threading.Tasks als Abhängigkeit, also kann nichts in letzterer auf die erste verweisen.

Wenn sie Rx zu .NET hinzufügen, tun sie das vielleicht, was Sie vorschlagen.

Bearbeiten:

Ich habe vielleicht sogar zu schnell gesprochen. Sehen Sie in der Dokumentation nach. Es scheint, dass das Interface IObservable<T> tatsächlich in% existiert. co_de% Assembly in .NET 4 und 4.5. Also was ich oben gesagt habe, ist kein absolut gültiger Grund. Ich überarbeite meinen Tippgrund auf "Weil sie Rx noch nicht in .NET integriert haben" anstatt "Es ist momentan wegen zirkulärer Abhängigkeiten nicht möglich."