Примеры реального мира Rx [дубликат]

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

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

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

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

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

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

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

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

Samuel McAravey опубликовал видео на Channel9, описывающее реальное приложение SilverLight, которое он создал с помощью RX. Он даже сделал его доступным на CodePlex.

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

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

Я написал более полную библиотеку для интеграции WPF / Silverlight и Rx, документация (РЕДАКТИРОВАТЬ: больше не паршивая!) Прямо сейчас, но вы можете проверить ее по адресу:

http: // www. reactiveui.net

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

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

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

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

Я адаптировал его к Silverlight, и он работает как шарм. Что является удивительно мощным, так это возможность фильтрации событий. Например, одно событие имеет тип "string", потому что никакой другой информации нет. Вместо того чтобы создавать сильно типизированный класс для каждого простого события, я создал класс, который раскрывает константы (чтобы не было волшебных строк) - например, 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 }); 

Нравится!