Utilizamos RX con gran éxito en dos proyectos (Silverlight UI) ya. Al principio, la intención era simplify the WCF access layer). Lo racional era que, en el peor de los casos, siempre podemos volver a las formas estándar (de devolución de llamada) de hacer las cosas sin afectar los niveles más altos de la IU.
Poco sabíamos que RX es como una droga adictiva: una vez que comienzas a usarla simplemente no hay vuelta. Al igual que un virus se extendió rápidamente de esta capa de comunicación de bajo nivel de todo el camino hasta componentes de interfaz:
- empezamos con el azúcar sintáctica sencilla de hacer que acceden a servicios WCF simple.
- partir de ahí fue un paso natural para extender RX a la mensajería asíncrona de servidor a cliente
- después de usar RX fusionar estas dos maneras para que el cliente se comunique con el servidor en una sola para ViewModels son agnósticos acerca de cómo ellos reciben mensajes era una opción predeterminada.
Y entonces fue completa capitulación:
- necesidad de manejar mensajes que llegan fuera de orden?
- ¿necesita actualizar una celda en la cuadrícula cuando cambia el precio?
- tienen un problema de rendimiento porque el cliente es bombardeado por mensajes del servidor?
- tienen alguna lógica de CEP rudimental para manejar?
Bueno, adivina qué, no hay operador de RX para eso;) (y si no hay - Usted puede simplemente escribir uno)
La parte más difícil de todo era superar que "mi-cerebro- duele-tan-malo "sensación de que todos en nuestro equipo experimentaron al principio. El cerebro de un simple mortal condicionado por años de código de manejo-mi-evento-por-esta-devolución de llamada simplemente no está conectado de la misma forma en que RX ve el mundo. Como resultado, el código RX (especialmente una vez que se hace cada vez más denso mientras se manejan escenarios cada vez más complicados) para una mente no preparada parece un abracadabra completo que de manera divertida resulta en un conejo sacado de un sombrero aparentemente vacío. Desafortunadamente, la realidad es que no hay lugar para la magia en el código de ejecución de producción y, por lo tanto, todo el equipo debe estar a bordo, lo que significa que todos tendrán que pasar por este doloroso proceso de reconfigurar sus cerebros en lo que al principio parece una forma muy poco natural.
Diría que es un factor humano y no la API RX en sí misma el mayor obstáculo para la adopción efectiva de RX. ¡Pero vale la pena!
Hace un tiempo vi esta publicación en el blog de Roger Alsing usando Rx para implementar un bus de mensajes que pensé que estaba bien: http: // rogeralsing.com/2010/01/23/rx-framework-building-a-message-bus/ – theburningmonk
La API sigue fluctuando, por lo que no he tomado una dependencia de Rx en ninguno de mis códigos de producción; ni estoy al tanto de que alguien más lo haga. –
De acuerdo, he tenido el mismo problema con Pex, cada nueva versión tenía tantos cambios y rompe mi código – theburningmonk