Примеры реального мира Rx

Возможный дубликат:
Хороший пример использования реактивных расширений

Я играл с Reactive Extension некоторое время, но в основном ограничивался обработкой/компоновкой событий, управляемых пользователем, в интерфейсе WPF.

Это такой мощный, новый способ делать асинхронное программирование, и мне любопытно, что с ним делают другие люди, и как вы думаете, что это может улучшить то, как мы сейчас делаем?

Ответ 1

Мы использовали RX с большим успехом на двух проектах (Silverlight UI) уже. В начале было сделано намерение упростить уровень доступа WCF). Разумно было то, что в худшем случае мы всегда можем вернуться к стандартному (обратному) способу делать вещи не влияя на более высокие уровни пользовательского интерфейса.

Мы мало знали, что RX похож на привыкание к наркотикам - как только вы начнете его использовать, просто нет возврата. Как вирус, он быстро распространился с этого уровня коммуникаций на низком уровне вплоть до компонентов пользовательского интерфейса:

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

И тогда это была полная капитуляция:

нужно обрабатывать сообщения, выходящие из строя?
нужно, чтобы вспышка ячейки на сетке при изменении цены?
возникает проблема производительности, потому что клиент подвергается бомбардировке сообщениями с сервера?
Есть ли какая-то рудиментарная логика CEP?

Ну, угадайте, что для этого есть RX-оператор;) (а если нет - вы можете просто написать один)

Самая сложная часть всего этого заключалась в том, чтобы преодолеть это "мое-мозговое-болит-так-плохое" чувство, что все в нашей команде испытали вначале. Мозг простого смертного, обусловленного многолетним кодированием handle-my-event-by-this-callback, просто не связан с тем, как RX видит мир. В результате RX-код (особенно когда он постепенно становится все более плотным при обработке более сложных сценариев) для неподготовленного ума выглядит как полная абракадабра, которая забавно приводит к тому, что кролик вытащил из кажущейся пустой шляпы. К сожалению, на самом деле нет места для магии в рабочем коде, и, следовательно, вся команда должна быть на борту, а это означает, что всем придется пройти через этот болезненный процесс переделания их мозгов в то, что кажется сначала очень неестественным способом.

Я бы сказал, что это человеческий фактор, а не сам RX API, который является самым большим препятствием для эффективного внедрения RX. Но мальчик это того стоит!

Ответ 2

Я написал более полную библиотеку для интеграции WPF/Silverlight и Rx, документация (EDIT: no longer lousy!) прямо сейчас, но вы можете проверить это:

http://www.reactiveui.net

Ответ 3

Я использовал RX для реализации загрузки данных в куски (например, студия управления сервером sql). Использование реактивных расширений для потоковой передачи данных из базы данных

Ответ 4

Самуэль МакАравей имеет видео на Channel9, описывающее реальный мир SilverLight приложение, которое он построил с использованием RX. Он даже сделал его доступным в CodePlex.

Кроме того, вот несколько практических применений, когда вы можете применять RX, даже если у вас нет асинхронных требований:

Если вы хотите разрешить пользователю прокручивать список, отображающий некоторые детали сбоку, запрос на детали синхронно может повредить вашу производительность прокрутки..Throttle() - ваш друг здесь.
Иногда вам нужно выполнить поиск, как только пользователь перестанет печатать. То же самое, используйте .Throttle, и вы в порядке.
Использовать Маршрутизированные сообщения в MVVM. Очень удобно использовать элементы списка, просто укажите CommandParameter = "{Binding}", и вы можете поймать их на уровне контейнера.

Ответ 5

Мы успешно используем Rx при загрузке данных из бэкэнд в приложении Silverlight. Недавно мы перенесли из SOAP-сервиса простое генерирование XML на сервере, и Rx пришел как раз вовремя, чтобы мы могли использовать его вместо WebClient или WebRequest (фактически мы теперь переносим WebClient в Observable, но, вероятно, перейдем к WebRequest).

У нас была ошибка пару дней назад; мы поняли, что URL-адреса запросов были настолько длинными, что они были усечены. К счастью, мы можем разделить запрос на несколько и объединить ответы, но решить, что использование только WebClient означало бы создание очереди и конечного автомата для обработки запросов последовательно... Вместо этого, используя Rx, мы могли бы просто разделить запрос в группах, делайте то, что мы делали раньше, но в призыве SelectMany, и мы закончили! Rx на помощь!

Ответ 6

Наверное, мое любимое решение прямо сейчас для Rx - использовать его как агрегатор событий. Посмотрите здесь:

http://jfromaniello.blogspot.com/2010/04/event-aggregator-with-reactive.html

Я адаптировал это для Silverlight, и это работает как шарм. Что удивительно мощно, так это способность фильтровать события. Для примера одно событие просто набирает "строка", потому что другой информации нет. Вместо создания строго типизированного класса для каждого простого события я создал класс, который предоставляет константы (поэтому нет магических строк), например BEGIN_BUSY (при вызове веб-службы), END_BUSY (когда это будет сделано) и др.

Чтобы подписаться, вы можете буквально сделать:

(from e in EventAggregator.Subscribe<string>() where e.Equals(BEGIN_BUSY) select true).Subscribe( evt=> { // Listening only to the BEGIN_BUSY event });

Люби его!