Hat RX Extensions das Problem der komplexen ereignisgesteuerten Programmierung "gelöst"?

Question

Ich habe Rx in einem neuen Finanzanalyseprojekt verwendet, das alle Daten asynchron empfängt. Ich war ziemlich erstaunt über meine persönliche Produktivität und wie viel verständlicher mein ereignisbasierter Code ist (im Gegensatz zum vorherigen Modell von Event-Handlern mit komplexen verschachtelten ifs und zufälligen Statusvariablen überall). Hat noch jemand eine Chance, damit zu spielen, und wenn ja, was sind deine Gedanken?

Answer 1

Ich glaube, die Reactive Extensions vereinfachen dramatisch einige Teile der komplexen, ereignisgesteuerten Programmierung, aber das Problem als Ganzes ist nicht "gelöst".

Es behandelt viele Situationen ist eine viel sauberere, eleganter Weise als bisher möglich. Es hilft jedoch nicht (unbedingt) immer auf der Erzeugungsseite einiger asynchroner Muster, bei denen die ereignisgesteuerte Programmierung immer noch schwierig ist. Rx konzentriert sich wirklich auf den Umgang mit der Subskriptionsseite des Events, aber nicht unbedingt auf die produktive Seite der Gleichung.

Für einige verschiedene Beispiele und eine Vorstellung dessen, was für zukünftige Versionen von C# in Betracht gezogen wird, um einige der komplexeren asynchronen Modelle zu handhaben, würde ich empfehlen, Luca Bolognese's PDC Talk zu sehen. Er präsentierte einige Ideen, an denen das Sprachteam arbeitet, um auf der Autorenseite der asynchronen Entwicklung zu helfen, wie zB eine "Iterator" -ähnliche Syntax, um direkt eine IAsync<T> mit Sprachfunktionen zur Unterstützung der Generierung der Ereignisse zu erzeugen.

Answer 2

Ich habe gerade einen Webcast über RX-Erweiterungen gesehen, nicht mit ihm gespielt, und fand die Erklärung zu kompliziert ... Ich dachte, die Schöpfer waren Architektin-Astronauten.

Für jetzt sehe ich nur nicht, wo ist das Problem mit klassischen Event-Handler ... Ich habe immer elegante Lösung gefunden, wenn ich asynchrone Kommunikation zwischen einem Client und einem Dienst verwenden musste.

Allerdings bin ich neugierig auf Erfahrungen von anderen Leuten mit diesem Framework, je nach Antworten auf diesen Thread, werde ich es noch einmal versuchen.

Answer 3

In http://channel9.msdn.com/posts/DC2010T0100-Keynote-Rx-curing-your-asynchronous-programming-blues erklärt Bart de Smet hervorragend, wie die Behandlung von Ereignisströmen als ein erstklassiges Konzept das Abstraktionsniveau erhöht, indem man darüber nachdenkt, wie man z. Throttle oder DistinctUntilChanged jedes Mal dringend mit vielen fehleranfälligen Boilerplate-Code. Diese Operatoren kapseln diese Verhaltensweisen in wiederverwendbarer und zusammensetzbarer Weise ein. Meine Meinung ist also, dass es Raum für weitere Entwicklungen gibt (siehe z. B. die Sorgen über kalte Observablen), aber diese Werkzeuge sollten in jeder Entwickler-Toolbox enthalten sein. Die üblichen Kontrollflusskonstrukte können es für die single-threaded Ausführung schneiden, aber in der heutigen hochgradig parallelen, verteilten Welt denke ich, dass Observable (oder besser, EventStream/Property) eine richtige Abstraktion ist.