私は、すべてのデータを非同期で受信する新しい財務分析プロジェクトでRxを使用しています。私は自分の生産性と、イベントベースのコードがどれほど理解しやすいかにかなり驚いています（複雑なネストされたifとランダムな状態変数がどこにでもある以前のモデルのイベントハンドラーとは対照的です）。他の誰かがそれで遊ぶ機会を得ましたか？もしそうなら、あなたの考えのいくつかは何ですか？
1972 次
4 に答える
11
Reactive Extensionsは、複雑なイベント駆動型プログラミングの一部を劇的に単純化すると思いますが、全体としての問題は「解決」されていません。
それは多くの状況を処理しますが、以前よりもはるかにクリーンでエレガントな方法です。ただし、イベント駆動型プログラミングが依然として困難な一部の非同期パターンの生成側では、（必然的に）常に役立つとは限りません。Rxは、実際にはイベントのサブスクリプション側の処理に重点を置いていますが、必ずしも方程式のプロデュース側を処理する必要はありません。
いくつかの明確なサンプル、およびより複雑な非同期モデルのいくつかを処理するためにC＃の将来のバージョンで何が検討されているかについては、LucaBologneseのPDCトークをご覧になることをお勧めします。IAsync<T>彼は、イベントの生成をサポートする言語機能を備えた、直接生成する構文のような「イテレータ」など、非同期開発のオーサリング側で支援するために言語チームが取り組んでいるいくつかのアイデアを提示しました。
于 2010-01-16T00:01:28.780 に答える
1
http://channel9.msdn.com/posts/DC2010T0100-Keynote-Rx-curing-your-asynchronous-programming-blues _、Bart de Smetは、イベントストリームをファーストクラスの概念として処理することで、実装方法を考えさせることで、抽象化のレベルを上げる方法をうまく説明しています。スロットルまたはDistinctUntilChangedは、エラーが発生しやすいボイラープレートコードが多数ある場合に必ず変更されます。これらの演算子は、これらの動作を再利用可能で構成可能な方法でカプセル化します。したがって、私の意見では、さらなる進化の余地は確かにあります（たとえば、コールドオブザーバブルに関する懸念を参照）が、これらのツールはすべての開発者のツールボックスに含まれている必要があります。通常の制御フロー構造はシングルスレッド実行のためにそれをカットするかもしれませんが、今日の高度に並行した分散された世界では、Observable（またはさらに良いのはEventStream / Property）が適切な抽象化だと思います。
于 2012-05-30T10:18:15.193 に答える
1
いいえ。複雑なイベント駆動型プログラミングの問題は、複雑なイベント駆動型の計算が動的な循環グラフで表されるという事実に起因します。そのグラフは、線形計画法のテキストを使用して便利に表現することはできません。唯一の解決策は、テキストプログラム表現を視覚的なグラフィック形式に変換したり、元に戻したりするための複数のツールを用意し、プログラムの正当性を動的および静的にチェックすることです。
于 2019-03-02T19:19:10.957 に答える
0
RX拡張機能に関するウェブキャストを見たばかりで、遊んでいませんでしたが、説明が複雑すぎることに気づきました...作成者は建築家の宇宙飛行士だと思いました。
今のところ、従来のイベントハンドラーの問題がどこにあるのかわかりません...クライアントとサービスの間で非同期通信を使用する必要がある場合、常に洗練された解決策を見つけました。
ただし、このフレームワークを使用している他の人の経験に興味があります。このスレッドの回答に応じて、もう一度試してみます。
于 2010-01-16T00:02:20.570 に答える