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?
Ich glaube, die Reactive Extensions vereinfachen einige Teile komplexer, ereignisgesteuerter Programmierung dramatisch, aber das Problem als Ganzes ist nicht "gelöst".
Es behandelt viele Situationen ist eine viel sauberere, eleganter 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 ist wirklich darauf fokussiert, die Subskriptionsseite des Events zu behandeln, aber nicht unbedingt die produktive Seite der Gleichung.
Für einige unterschiedliche Beispiele und eine Vorstellung davon, was für zukünftige Versionen von C # für einige der komplexeren asynchronen Modelle in Betracht gezogen wird, empfehle ich PDC Talk von Luca Bolognese . 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 ein IAsync<T> mit Sprachfeatures zu erzeugen, die die Generierung der Ereignisse unterstützen.
In Ссылка erklärt Bart de Smet hervorragend, wie die Behandlung von Event-Streams als erstklassiges Konzept erhöht das Abstraktionsniveau, indem es Sie darüber nachdenkt, wie Sie 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, ist Observable (oder besser, EventStream / Property) eine richtige Abstraktion.
Ich habe gerade einen Webcast über RX-Erweiterungen gesehen, der nicht mit ihm gespielt wurde, und fand die Erklärung zu kompliziert ... Ich dachte, die Schöpfer wären Architektin-Astronauten.
Im Moment sehe ich nur nicht, wo das Problem mit dem klassischen Event-Handler ist ... Ich habe immer eine elegante Lösung gefunden, als ich die asynchrone Kommunikation zwischen einem Client und einem Service 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.
Tags und Links .net c# reactive-programming system.reactive