Die neuen IObservable / IObserver-Frameworks in der System.Reactive-Bibliothek in .NET 4.0 sind sehr aufregend (siehe dies und dieser Link).
Es ist vielleicht zu früh, um darüber zu spekulieren, aber wird es auch ein (aus Mangel an einem besseren Begriff) IQueryable-ähnliches Framework geben, das für diese neuen Schnittstellen ebenfalls gebaut wird?
Ein besonderer Anwendungsfall wäre die Unterstützung bei der Vorverarbeitung von Ereignissen an der Quelle und nicht in der Kette der empfangenden Aufrufe. Wenn Sie zum Beispiel eine sehr "gesprächige" Ereignisschnittstelle haben, empfängt die Verwendung von Subscribe().Where(...) alle Ereignisse über die Pipeline und der Client filtert sie.
Ich frage mich, ob es etwas Ähnliches wie IQueryableObservable geben wird, wobei diese LINQ-Methoden in eine 'intelligente' Subscribe -Implementierung in einer Quelle 'kompiliert' werden. Ich kann mir bestimmte Netzwerkserverarchitekturen vorstellen, die ein solches Framework verwenden könnten. Oder wie wäre es mit einem Add-On zu SQL Server (oder irgendeinem anderen RDBMS), das es ermöglicht, dass der .NET-Code neue Datenbenachrichtigungen (Auslöser im Code) erhält und diese Benachrichtigungen serverseitig gefiltert werden müssten.
Nun, Sie haben es in der neuesten Version von Rx in Form einer Schnittstelle namens IQbservable (ausgesprochen als IQueryableObservable). Bleiben Sie dran für ein Channel 9 Video zu diesem Thema, das Anfang nächster Woche erscheint.
Um dieses Feature ein wenig zu verorten, sollte man wissen, dass das Rx / Ix-Puzzle drei orthogonale Achsen hat:
Die gesamte IQbservable-Schnittstelle (bei der es sich um die doppelte IQueryable- und die Ausdrucksbaumdarstellung einer IObservable-Abfrage handelt) ist der letzte Punkt. Manchmal verwirren die Leute den Akt der Query-Übersetzung (das "Wie") mit Remoting-Aspekten (das "Wo"). Normalerweise übersetzen Sie Abfragen in einige Zielsprachen (z. B. WQL, PowerShell, DSQLs für Cloud-Benachrichtigungsdienste usw.) und remote in einige Zielsysteme kann entkoppelt werden. Sie können beispielsweise die Ausdrucksbaumdarstellung für die lokale Abfrageoptimierung verwenden.
Im Hinblick auf mögliche Sicherheitsbedenken unterscheidet sich dies nicht von den IQueryable-Funktionen. In der Regel wird nur die Ausdruckssprache entfernt und keine "wirklich seitenwirksamen" Operatoren (was auch immer das für andere Sprachen als fundamental funktionale bedeutet). Insbesondere bleiben die Subscribe- und Run-Operationen lokal und führen Sie aus der abfragbaren Monade heraus (wodurch die Übersetzung ausgelöst wird, genau wie GetEnumerator in der Welt von IQueryable). Wie du den Akt des Abonnierens abgelenkt hast, überlasse ich der Vorstellungskraft des Lesers.
Beginne noch heute mit den neuesten Bits und lass es uns wissen was denkst du. Bleiben Sie auch auf dem kommenden Channel 9-Video über dieses neue Feature, einschließlich einer Diskussion über einige seiner Design-Philosophie.
Das klingt nach einer interessanten Möglichkeit, aber ich hätte einige Bedenken, dies umzusetzen.
1) Ebenso wie Sie nicht-triviale Lambda-Ausdrücke, die von IQueryable verwendet werden, nicht serialisieren können, wäre das Serialisieren dieser für Rx ähnlich schwierig. Sie möchten wahrscheinlich mehrzeilige und Anweisungslambdas als Teil dieses Frameworks serialisieren können. Um das zu tun, müssten Sie wahrscheinlich etwas wie Erik Meijers andere Lieblingsprojekte - Dryad und Volta - umsetzen.
2) Selbst wenn Sie diese Lambda-Ausdrücke serialisieren könnten, wäre ich besorgt über die Möglichkeit, auf dem Server, der vom Client gesendet wird, beliebigen Code laufen zu lassen. Dies könnte leicht zu einem Sicherheitsproblem führen, das weitaus größer ist als das Cross-Site-Scripting. Ich bezweifle, dass der potenzielle Vorteil, den Client zu ermöglichen, Ausdrücke an den Server zu senden, um die Auswirkungen der Sicherheitslücke zu überwiegen, überwiegt.
8 Jahre in die Zukunft: Ich stolperte über Qactive (früher Rxx), ein Rx.Net basierend auf einem abfragbaren reaktiven tcp-Server-Provider Es ist die Antwort auf die "Frage in Frage"
Server
%Vor%Kunde
%Vor%Es ist überwältigend, dass die Kunden sagen können, was und wie oft sie die Daten erhalten möchten, und der Server kann immer noch einschränken und steuern, wann, wie häufig und wie viele Daten zurückgegeben werden.
Weitere Informationen zu diesem Ссылка
Ein anderer Blog.sample
Es scheint, basierend auf einem neuen channel9 Interview , dass es LINQ-Unterstützung für IObserver / IObservable in der BCL von .NET 4 geben wird.
Es wird jedoch im Wesentlichen LINQ-to-Objects-Style-Abfragen geben, so dass es in diesem Stadium nicht wie ein "intelligenter Subscribe" aussieht, wie Sie es nennen. Das ist, soweit die grundlegenden Implementierungen in .NET 4 gehen. (Aus meinem Verständnis aus dem obigen Interview)
Nachdem das gesagt wurde, kann das Reactive Framework (Rx) detailliertere Implementierungen von IObserver / IObservable enthalten, oder Sie können vielleicht Ihre eigene Übergabe in Expression<Func...> für die Subscribe paramaters und benutze dann den Ausdrucksbaum von Func , um auf eine intelligentere Weise zu abonnieren, die zu dem Ereigniskanal passt, den du abonnierst.
Tags und Links linq system.reactive