私は別のスレッドでmini-discussion on the topicを持っていて、被験者の「悪い」側に人々の意見を持っていたいと思っています。RX被験者 - 避けたいのですか？
RXフォーラムを頻繁に使用する人は、E.Meijer does not like Subjectsを知っています。私はRX作成者の意見に最も深い敬意を払いますが、私は被験者を数年にわたって複数のプロジェクトで非常に幅広く使用してきており、そのために建築上の問題やバグはありませんでした。
Subjectでobservableを完了した後、新しいサブスクライバがイベントを受け取る前に、サブジェクトを再インスタンス化する必要があります。
"コードの匂い"と "好きではない"は、 "実用的な"例でサポートする必要があります。件名を使用するとバグや問題につながる可能性がありますか？あるいは、あなたがそれらが簡単で無害であると思うかもしれません - そして、それらが使用されるべき領域を定義しようとしてください。
Erik Meijerは純粋に機能的な方法で考えています - 被験者はRxの可変変数です。ですから、一般的な使い方では、Subjectを使用することはThinking Functionallyを回避する方法であり、あまり使用すると上流に行こうとしています。
ただし、サブジェクトは、.NETの非機能的な世界と接続するときに非常に便利です。イベントまたはコールバックメソッドをラップしますか？被験者はそれに最適です。既存のコードにRxの「インターフェース」を入れようとしていますか？件名を使用する！
lazy evalのために反応コンビネータが複製されるときはいつでも、Subject/Publishを使用します。
しかし、カジュアルな使用のために、私は被験者が少し重いと感じます - OnNextは潜在的なボトルネックかもしれません - プロファイリング中のホットスポットとして表示されます。
あなたが知っているオブザーバブルについても、それは明確であると感じています。
コメント投稿者の多くがお互いに話しているようです。
前回私がSubjectを使用したのは、何か起こったときに私に電話をかけるために、デリゲートを初期化コールでミドルウェアに渡す必要があったときでした。デリゲートにはおなじみのイベントargsシグニチャがありましたが、イベントがなかったので、FromEventを使用できませんでした。
私はそれについて悪くは感じなかった - 私は他の選択肢を見なかった。
基本的には、私が何らかの出来事を出してそれをRxの世界に入れているとき、またはまだ到着していない未来の加入者のハンドルが必要なときにのみ、主題を使用しました。被験者は私が今持っているものを後の加入者にリンクさせる。
あなたのコメントから、 'Observable.FromEvent'メソッドが当時の通常のデリゲートに対応していなかったと推測します。あるいは、彼らは依然としてドン・トンではなく、単にデリゲートではなく「イベント」であることを委任します。私はそれをチェックしなければならない。しかし、あなたがしたことを示すためにいくつかのコードを投稿していただけますか？私はあなたが 'Subject
公開APIの一部としてSubject<T>を使用することを慎重に考える理由の1つは、懸案事項が混在していることです。観察者は、観察可能なものとは異なる懸念事項である。
何いくつかの悪人観察者は、それが唯一のオブザーバーになるはずだった？Subject<T>上OnNextまたはOnCompletedまたはOnErrorを呼び出す場合
APIの一部ではなく、プライベートなバッキングフィールドとしてサーバーに埋め込んでも、それが二重の役割を果たすという事実だけが邪魔になります。それをバッキングフィールドとして使用する場合でも、あなたはそれがある役割/関心事、すなわち観察可能なものの実行を期待しているだけです。しかし、それは2つのことをする可能性があり、それはちょうど精神的に邪魔です。
妥当と思われます。私は既にイベントをラップする方法、つまりObservable.FromEvent（Pattern）があります。 –
私は彼が単にイベントと非同期呼び出しをラップするだけでなく、それらのデータを使用することを意味すると考えています。たとえば、 'BeginRead'と' EndRead'の非同期呼び出しをラップすると、 'EndRead'は' BeginRead'に渡された可変バイト配列にアクセスしなければならない実際のデータを取得するために読み込まれたバイト数を返します。 – Tyson
良い説明。 – axel22