5
.NET Reactive Extensionsでサブジェクトが推奨されないのはなぜですか？
私は現在、.NETのReactive Extensionsフレームワークに慣れつつあり、私が見つけたさまざまな導入リソース（主にhttp://www.introtorx.com）に取り組んでいます 私たちのアプリケーションには、ネットワークフレームを検出するいくつかのハードウェアインターフェイスが含まれます。これらはIObservableになります。次に、これらのフレームを使用したり、データに対して何らかの変換を実行して新しいタイプのフレームを生成したりするさまざまなコンポーネントがあります。たとえば、n番目のフレームごとに表示する必要がある他のコンポーネントもあります。Rxがアプリケーションに役立つと確信していますが、IObserverインターフェイスの実装の詳細に苦労しています。 私が読んでいたリソースのほとんど（すべてではないにしても）は、IObservableインターフェイスを自分で実装するのではなく、提供された関数またはクラスの1つを使用するべきだと述べています。私の研究から、を作成するSubject<IBaseFrame>と必要なものが提供されるように見えSubject<IBaseFrame>ます。ハードウェアインターフェイスからデータを読み取り、インスタンスのOnNext関数を呼び出す単一のスレッドが必要です。異なるIObserverコンポーネントは、そのサブジェクトから通知を受け取ります。 私の混乱は、このチュートリアルの付録に書かれているアドバイスから来ています： サブジェクトタイプの使用は避けてください。Rxは事実上、関数型プログラミングのパラダイムです。サブジェクトを使用するということは、状態を管理していることを意味します。状態の変化と非同期プログラミングの両方を同時に処理することは、正しく行うのが非常に困難です。さらに、多くの演算子（拡張メソッド）は、サブスクリプションとシーケンスの正確で一貫したライフタイムが維持されるように注意深く書かれています。主題を紹介すると、これを壊すことができます。サブジェクトを明示的に使用すると、将来のリリースでもパフォーマンスが大幅に低下する可能性があります。 私のアプリケーションはパフォーマンスが非常に重要です。Rxパターンを使用してパフォーマンスをテストしてから、本番用コードに移行します。ただし、Subjectクラスを使用してRxフレームワークの精神に反することを行っていること、およびフレームワークの将来のバージョンがパフォーマンスを低下させることを心配しています。 私がやりたいことを行うより良い方法はありますか？ハードウェアポーリングスレッドは、オブザーバーの有無に関係なく継続的に実行されるため（HWバッファーはそれ以外の場合にバックアップされます）、これは非常にホットなシーケンスです。次に、受信したフレームを複数のオブザーバーに渡す必要があります。 どんなアドバイスもいただければ幸いです。