24

重複の可能性：
リアクティブエクステンションの使用の良い例

私はしばらくの間ReactiveExtensionをいじっていますが、ほとんどの場合、WPFフロントエンド内でのユーザー主導のイベントの処理/作成に限定されています。

これは、非同期プログラミングを行うための非常に強力で新しい方法です。他の人がそれを使って何をしているのか知りたいのですが、現在のやり方をどこで改善できると思いますか？

4

5 に答える 5

39

RX はすでに 2 つのプロジェクト (Silverlight UI) で大きな成功を収めています。当初の目的はWCF アクセス レイヤーを単純化することでした) 合理的な理由は、最悪のシナリオでは、より高いレベルの UI に影響を与えることなく、常に標準 (コールバック) の方法に戻すことができるということでした。

RX が常習性のドラッグのようなものであることは、ほとんど知られていませんでした。一度使い始めると、元に戻ることはありません。ウイルスのように、この低レベルの通信レイヤーから UI コンポーネントまで急速に広がります。

  • WCF サービスへのアクセスを簡単にするために、単純な構文糖衣から始めました。
  • そこから、RX をサーバーからクライアントへの非同期メッセージングに拡張するのは自然なステップでした。
  • その後、RX を使用して、クライアントがサーバーと通信するこれらの方法の両方を 1 つにマージし、ビューモデルがメッセージの受信方法に依存しないようにすることがデフォルトのオプションでした。

そして、それは完全な降伏でした：

  • 順不同のメッセージを処理する必要がありますか?
  • 価格が変化したときにグリッド上のセルをフラッシュする必要がありますか?
  • サーバーからのメッセージがクライアントに送信されたため、パフォーマンスの問題が発生しましたか?
  • 処理する基本的な CEP ロジックがありますか?

まあ、そのための RX 演算子があると思います ;) (ない場合は、簡単に記述できます)

最も困難だったのは、チームの全員が最初に経験した「頭が痛い」という感覚を克服することでした。何年にもわたるこのコールバックでイベントを処理するコーディングによって条件付けられた単なる人間の脳は、RX が世界を見る方法とは配線されていません。その結果、準備ができていない心の RX コード (特に、ますます複雑なシナリオを処理しながら次第に密度が高くなる場合) は、完全なアブラカダブラのように見え、面白いことに、一見空の帽子からウサギが引き出されます。残念ながら、現実には、本番環境で実行されるコードに魔法の余地はないため、チーム全体が参加する必要があります。つまり、最初は非常に不自然に思える方法で、頭脳を再配線するこの苦痛なプロセスを誰もが経験しなければならないということです。

RX を効果的に採用する上で最大の障害となるのは、RX API 自体ではなく人的要因だと思います。しかし、男の子はそれだけの価値があります！

于 2010-05-21T15:05:24.493 に答える
11

WPF/Silverlight と Rx を統合するためのより完全なライブラリを作成しました。ドキュメントは現在 (編集: もうお粗末ではありません!) ですが、次の場所で確認できます。

http://www.reactiveui.net

于 2010-06-22T05:34:38.213 に答える
3

Samuel McAravey has a video on Channel9 describing a real-world SilverLight application he built using RX. He even made it available on CodePlex.

Also, here are a few of practical uses when you can apply RX even if you do not have asynchronous requirements:

  • If you want to allow user scroll through a list displaying some details on the side, querying for details synchronousely might hurt your scrolling performance. .Throttle() is your friend here.
  • Sometimes you need to perform a lookup as soon as user stops typing. Same thing, use .Throttle and you are fine.
  • Use Routed Commmands in MVVM. Very nice for using on list items, just specify CommandParameter="{Binding}" and you can catch these on the container level.
于 2010-05-21T16:15:33.827 に答える
3

Silverlight アプリでバックエンドからデータをロードするときに、Rx を正常に使用しています。私たちは最近、サーバー上でプレーンな XML 生成を行う SOAP サービスから移行し、WebClient や WebRequest の代わりに Rx を使用できるようになりました (実際には、現在 WebClient を Observable でラップしていますが、おそらく WebRequest に移行する予定です)。

数日前にバグがありました。リクエスト URL が長すぎて切り捨てられていることに気付きました。幸いなことに、リクエストを複数に分割してレスポンスを連結することができますが、WebClient のみを使用すると、リクエストを順番に処理するためのキューとステート マシンを作成することになります。代わりに、Rx を使用すると、リクエストをグループに分割することができます。 、前に行ったことを行いますが、SelectMany の呼び出しで完了です! Rxが助けに来ます！

于 2010-06-23T12:41:19.497 に答える
2

おそらく、Rx の現在のお気に入りのソリューションは、Rx をイベント アグリゲーターとして使用することです。ここを見てください：

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

これをSilverlightに適応させたところ、魅力的に機能します。驚くほど強力なのは、イベントをフィルタリングする機能です。たとえば、他の情報がないため、1 つのイベントは単に「文字列」と入力されます。単純なイベントごとに厳密に型指定されたクラスを作成する代わりに、定数を公開するクラスを作成しました (したがって、マジック ストリングはありません)。たとえば、BEGIN_BUSY (Web サービスが呼び出されているとき)、END_BUSY (完了したとき)、等

サブスクライブするには、文字通り次のようにします。

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

大好きです！

于 2010-08-16T22:09:42.793 に答える