Extensiones RX ha “resuelto” el problema de la programación dirigida por eventos complejos?

Question

He estado usando Rx en un nuevo proyecto de análisis financiero que recibe todos los datos de forma asíncrona. He estado muy sorprendido por mi productividad personal y cuánto más comprensible mi código basado en eventos es (en comparación con el modelo anterior de controladores de eventos con ifs anidados complejos y variables de estado al azar por todas partes.). Alguien más tuvo la oportunidad de jugar con él, y si es así ¿cuáles son algunos de sus pensamientos?

Answer 1

Creo que las extensiones reactivas simplificar drásticamente algunas porciones de programación compleja, orientada a eventos, pero el problema en su conjunto no es "resuelto".

Lo hace manejar muchas situaciones es mucho más limpio, de manera más elegante que antes era posible. Sin embargo, no (necesariamente) siempre ayuda en el lado de la generación de algunos patrones asincrónicos, donde la programación orientada a eventos sigue siendo difícil. Rx realmente se centra en el tratamiento de los aspectos de suscripción del evento, pero no necesariamente el lado de la producción de la ecuación.

Para algunas muestras distintas, y una idea de lo que está siendo considerado para futuras versiones de C # para manejar algunos de los modelos más complejos asíncronos, me gustaría recomendar viendo Luca boloñesa PDC Talk . Presentó algunas ideas del equipo de traducción está trabajando para ayudar en el lado de autoría del desarrollo asincrónico, como un "repetidor" sintaxis similar para producir un IAsync<T> directamente, con las características del lenguaje para apoyar la generación de los acontecimientos.

Answer 2

http: //channel9.msdn .com / mensajes / DC2010T0100-Keynote-Rx-curado-su-asíncrono de programación-blues , Bart de Smet excelentemente explica cómo manejar flujos de eventos como un concepto de primera clase eleva el nivel de abstracción, haciendo que pensar acerca por ejemplo, cómo se implementa. DistinctUntilChanged acelerador o cada vez que imperativamente con una gran cantidad de código repetitivo propenso a errores. Estos operadores encapsulan estos comportamientos en una forma reutilizable y componibles. Así que mi opinión es que no hay margen para seguir la evolución (véase por ejemplo las preocupaciones acerca de los observables en frío), pero estas herramientas debe estar en la caja de herramientas de todos los desarrolladores. Las construcciones de flujo de control habituales pueden cortar para la ejecución de un único subproceso, pero en altamente concurrente el mundo de hoy, distribuida, creo observable (o mejor aún, EVENTSTREAM / Propiedad) es una abstracción adecuada.

Answer 3

acabo de ver una transmisión en extensiones RX, no jugó con él, y encontré la explicación demasiado complicado ... pensé que los creadores fueron los astronautas arquitecto.

Por ahora no veo dónde está el problema con el controlador de eventos clásicos ... siempre he encontrado solución elegante cuando tuve que utilizar la comunicación asíncrona entre un cliente y un servicio.

Sin embargo tengo curiosidad con las experiencias de otras personas con este marco, en función de las respuestas de este hilo, voy a dar otra oportunidad.

Answer 4

No. El problema de la programación orientada a eventos complejo se deriva del hecho de que cualquier cálculo evento impulsado complejo está representado con un gráfico cíclico dinámico. Ese gráfico no se puede representar convenientemente usando el texto de programación lineal. La única salida es tener múltiples herramientas para convertir la representación textual del programa de forma gráfica visual y hacia atrás, y para comprobar la corrección del programa de forma dinámica y estática.