¿Ha resuelto RX Extensions el problema de la programación basada en eventos complejos?

Question

He estado usando Rx en un nuevo proyecto de análisis financiero que recibe todos los datos de forma asincrónica. Me he sorprendido bastante de mi productividad personal y de lo mucho más comprensible que es mi código basado en eventos (a diferencia del modelo anterior de controladores de eventos con ifs anidados complejos y variables de estado aleatorias en todas partes). Alguien más tiene la oportunidad de jugar con él, y si es así, ¿cuáles son algunos de sus pensamientos?

Answer 1

Creo que las Extensiones reactivas simplifican drásticamente algunas partes de la programación compleja basada en eventos, pero el problema en su conjunto no está "resuelto".

Maneja muchas situaciones es una manera mucho más limpia, más elegante que antes. Sin embargo, no siempre ayuda (necesariamente) en el lado de generación de algunos patrones asincrónicos, donde la programación impulsada por eventos aún es difícil. Rx realmente se enfoca en manejar el lado de la suscripción del evento, pero no necesariamente en el lado de la ecuación productora.

Para algunas muestras distintas, y una idea de lo que se está considerando para futuras versiones de C# para manejar algunos de los modelos asíncronos más complejos, recomendaría ver Luca Bolognese's PDC Talk. Presentó algunas ideas en las que el equipo de lenguaje está trabajando para ayudar en el lado de autoría del desarrollo asíncrono, como una sintaxis tipo "iterador" para producir un IAsync<T> directamente, con funciones de lenguaje para admitir la generación de los eventos.

Answer 2

Acabo de ver un webcast en extensiones RX, no toqué con él, y encontré la explicación demasiado complicada ... Pensé que los creadores eran astronautas de arquitectura.

Por ahora, simplemente no veo dónde está el problema con el controlador de eventos clásico ... Siempre he encontrado una solución elegante cuando tuve que usar la comunicación asincrónica entre un cliente y un servicio.

Sin embargo, estoy curioso con las experiencias de otras personas con este marco, dependiendo de las respuestas de este hilo, lo intentaré de nuevo.

Answer 3

En http://channel9.msdn.com/posts/DC2010T0100-Keynote-Rx-curing-your-asynchronous-programming-blues, Bart de Smet explica de manera excelente cómo manejar las secuencias de eventos como un concepto de primera clase eleva el nivel de abstracción al hacerte pensar acerca de cómo implementar, por ejemplo. Throttle o DistinctUntilChanged cada vez de manera imperativa con muchos códigos repetitivos propensos a errores. Estos operadores encapsulan estos comportamientos de una manera reutilizable y composable. Así que mi opinión es que definitivamente hay espacio para una mayor evolución (ver por ejemplo las preocupaciones sobre los observables en frío), pero estas herramientas deberían estar en la caja de herramientas de cada desarrollador. Las construcciones de flujo de control habituales pueden cortarlo para la ejecución de un único subproceso, pero en el mundo altamente concurrente distribuido de hoy, creo que Observable (o mejor aún, EventStream/Propiedad) es una abstracción adecuada.