Решил ли RX Extensions проблему сложного событийно-ориентированного программирования?

Question

Я использую Rx в новом проекте финансового анализа, который получает все данные асинхронно. Я был очень удивлен моей личной производительностью и тем, насколько более понятен мой код, основанный на событиях (в отличие от предыдущей модели обработчиков событий со сложными вложенными if и случайными переменными состояния везде). У кого-нибудь еще был шанс поиграть с ним, и если да, то что вы думаете?

Answer 1

Я считаю, что Reactive Extensions значительно упрощают некоторые части сложного программирования, управляемого событиями, но проблема в целом не «решена».

Он справляется со многими ситуациями гораздо чище, более элегантно, чем это было возможно ранее. Тем не менее, это не обязательно (обязательно) помогает на стороне генерации некоторых асинхронных шаблонов, где программирование на основе событий все еще сложно. Rx действительно сосредоточен на обработке подписной стороны события, но не обязательно производящей стороны уравнения.

Для некоторых отдельных примеров и идеи того, что рассматривается в будущих версиях C # для обработки некоторых из более сложных асинхронных моделей, я бы рекомендовал посмотреть Обсуждение PDC Луки Болоньезе . Он представил некоторые идеи, над которыми работает языковая группа, чтобы помочь на стороне разработки асинхронной разработки, например, синтаксис типа «итератор» для непосредственного создания IAsync<T> с функциями языка для поддержки генерации событий.

Answer 2

В http://channel9.msdn.com/posts/DC2010T0100-Keynote-Rx-curing-your-asynchronous-programming-blues, Барт де Смет превосходно объясняет, как обработка потоков событий как первоклассная концепция повышает уровень абстракции, заставляя вас думать о том, как вы реализуете, например. Throttle или DistinctUntilChanged каждый раз обязательно с большим количеством подверженного ошибкам шаблонного кода. Эти операторы инкапсулируют эти поведения многоразовым и составным способом. Поэтому я считаю, что, безусловно, есть место для дальнейшей эволюции (см., Например, опасения по поводу холодных наблюдаемых), но эти инструменты должны быть в наборе инструментов каждого разработчика. Обычные конструкции потока управления могут обрезать его для однопоточного исполнения, но в сегодняшнем сильно параллельном, распределенном мире, я думаю, Observable (или даже лучше, EventStream / Property) - правильная абстракция.

Answer 3

Нет. Проблема программирования, основанного на сложных событиях, связана с тем, что любые вычисления, управляемые сложными событиями, представлены динамическим циклическим графом. Этот график не может быть удобно представлен с использованием текста линейного программирования. Единственный выход - иметь несколько инструментов для преобразования текстового представления программы в визуальную графическую форму и обратно и динамически и статически проверять правильность программы.

Answer 4

Я только что видел веб-трансляцию по расширениям RX, не играл с ней и нашел объяснение слишком сложным ... Я думал, что создатели были астронавтами-архитекторами.

Пока я просто не вижу, в чем проблема классического обработчика событий ... Я всегда находил элегантное решение, когда мне приходилось использовать асинхронную связь между клиентом и службой.

Однако мне любопытно узнать, что другие люди используют в этой среде, в зависимости от ответов в этой теме, я попробую еще раз.