Extensions RX a « résolu » le problème de l'événement complexe programmation par?

Question

Je me sers de Rx sur un nouveau projet d'analyse financière qui reçoit toutes les données de manière asynchrone. Je suis assez étonné de ma productivité personnelle et combien plus compréhensible mon code en fonction de l'événement est (par opposition au modèle précédent des gestionnaires d'événements avec ifs imbriqués complexes et variables d'état aléatoires partout.). Quelqu'un at-il eu la chance de jouer avec lui, et si oui, quelles sont vos pensées?

Answer 1

Je crois que les extensions réactives simplifient considérablement certaines parties de la programmation complexe, événementiel, mais le problème dans son ensemble est pas « résolu ».

Il ne gère de nombreuses situations est beaucoup plus propre, de manière plus élégante qu'auparavant. Cependant, il n'a pas (nécessairement) aide toujours du côté de la génération de certains modèles asynchrones, où la programmation événementielle est encore difficile. Rx est vraiment concentré sur la manipulation du côté de souscription de l'événement, mais pas nécessairement le côté production de l'équation.

Pour certains échantillons distincts, et une idée de ce qui est envisagé pour les versions futures de C # pour traiter certains des modèles asynchrones plus complexes, je vous recommande de regarder PDC Talk Luca Bolognese. Il a présenté quelques idées l'équipe linguistique travaille à aider sur le côté de la création du développement asynchrone, comme un « iterator » comme la syntaxe pour produire un IAsync<T> directement, avec des caractéristiques linguistiques pour soutenir la génération des événements.

Answer 2

http: //channel9.msdn .com / messages / DC2010T0100-Keynote-Rx-durcissement-votre-asynchrone programmation-blues , Bart de Smet explique parfaitement comment manipuler les flux d'événements comme un concept de première classe augmente le niveau d'abstraction en vous faisant penser à comment vous mettre en œuvre par exemple. Ou gaz DistinctUntilChanged chaque fois impérieusement avec beaucoup de code boilerplate sujettes à erreur. Ces opérateurs encapsulent ces comportements d'une manière réutilisable et composable. Donc, mon opinion est qu'il ya certainement place pour l'évolution future (voir par exemple les préoccupations au sujet de froid observables), mais ces outils devrait être dans la boîte à outils de tous les développeurs. Les constructions de contrôle de flux habituels peuvent couper pour l'exécution monothread, mais dans le monde hautement concurrent d'aujourd'hui, distribué, je pense Observable (ou mieux encore, EVENTSTREAM / Propriété) est une abstraction correcte.

Answer 3

Je viens de voir une webdiffusion sur les extensions RX, pas joué avec elle, et a trouvé l'explication trop compliqué ... Je pensais que les créateurs étaient astronautes architecte.

Pour l'instant, je ne vois pas où est le problème avec gestionnaire d'événements classique ... Je l'ai toujours trouvé une solution élégante quand je devais utiliser la communication asynchrone entre un client et un service.

Cependant, je suis curieux des expériences d'autres personnes avec ce cadre, selon les réponses de ce fil, je vais donner une autre chance.

Answer 4

Non. Le problème de la programmation par des événements complexes provient du fait que tout calcul entraîné par un événement complexe est représenté par un diagramme cyclique dynamique. Ce graphique ne peut pas être représenté en utilisant commodément le texte de la programmation linéaire. La seule solution est d'avoir plusieurs outils pour convertir la représentation du programme textuel à la forme graphique visuelle et le dos, et de vérifier la correction du programme dynamique et statique.