As extensões RX “resolveram” o problema da programação complexa orientada a eventos?

Question

Estou usando o Rx em um novo projeto de análise financeira que recebe todos os dados de forma assíncrona.Fiquei bastante surpreso com minha produtividade pessoal e com o quão mais compreensível meu código baseado em eventos é (em oposição ao modelo anterior de manipuladores de eventos com ifs aninhados complexos e variáveis ​​de estado aleatórias em todos os lugares).Alguém mais teve a chance de brincar com ele e, em caso afirmativo, quais são seus pensamentos?

Answer 1

Acredito que as Extensões Reativas simplificam drasticamente algumas partes da programação complexa orientada a eventos, mas o problema como um todo não está "resolvido".

Ele lida com muitas situações de uma maneira muito mais limpa e elegante do que era possível anteriormente.No entanto, isso nem sempre ajuda (necessariamente) no lado da geração de alguns padrões assíncronos, onde a programação orientada a eventos ainda é difícil.Rx está realmente focado em lidar com o lado da assinatura do evento, mas não necessariamente com o lado da produção da equação.

Para alguns exemplos distintos e uma ideia do que está sendo considerado para versões futuras do C# para lidar com alguns dos modelos assíncronos mais complexos, recomendo assistir Palestra PDC de Luca Bolognese.Ele apresentou algumas idéias nas quais a equipe de linguagem está trabalhando para ajudar no lado da autoria do desenvolvimento assíncrono, como um "iterador" como sintaxe para produzir um IAsync<T> diretamente, com recursos de linguagem para apoiar a geração dos eventos.

Answer 2

Em http://channel9.msdn.com/posts/DC2010T0100-Keynote-Rx-curing-your-asynchronous-programming-blues, Bart de Smet explica excelentemente como lidar com fluxos de eventos como um conceito de primeira classe aumenta o nível de abstração, fazendo você pensar sobre como implementar, por exemplo.Throttle ou DistinctUntilChanged sempre imperativamente com muitos códigos padrão propensos a erros.Esses operadores encapsulam esses comportamentos de uma forma reutilizável e combinável.Portanto, a minha opinião é que há certamente espaço para uma maior evolução (ver, por exemplo,as preocupações com observáveis ​​frios), mas essas ferramentas devem estar na caixa de ferramentas de todo desenvolvedor.As construções usuais de fluxo de controle podem ser suficientes para execução de thread único, mas no mundo distribuído e altamente simultâneo de hoje, acho que Observable (ou melhor ainda, EventStream/Property) é uma abstração adequada.

Answer 3

Acabei de ver um webcast sobre extensões RX, não brinquei com ele e achei a explicação muito complicada...Achei que os criadores fossem astronautas arquitetos.

Por enquanto não vejo onde está o problema com o manipulador de eventos clássico...Sempre encontrei soluções elegantes quando tive que usar comunicação assíncrona entre um cliente e um serviço.

Porém estou curioso com experiências de outras pessoas com esse framework, dependendo das respostas deste tópico, vou tentar novamente.

Answer 4

Não.O problema da programação orientada a eventos complexos decorre do fato de que qualquer computação dirigida a eventos complexos é representada por um gráfico cíclico dinâmico.Esse gráfico não pode ser representado convenientemente usando texto de programação linear.A única saída é ter múltiplas ferramentas para converter a representação textual do programa em formato gráfico visual e vice-versa, e verificar a correção do programa de forma dinâmica e estática.