私のライブラリはリアクティブエクステンションを知っていますか？

Question

Reactive Extensions for .NETに関心が高まってきています。私のアプリケーションにはデータ取得システムが関係しているので、おそらく私のドメインライブラリの中核クラスや概念さえも、Rxの概念を使うことで利益を得るでしょう。

私の疑問は、私がドメインモデルをRxタイプとインターフェースで「汚染する」べきかどうかです。または、クライアントコードでのみRxを使用して「クリーン」にしておく必要がありますか？

一方で、クリーンアーキテクトの賛同者（ボブ叔父さんの大部分）は、「あなたはフレームワークに依存しない」と主張します。それは意味があります。

一方、私はすでに.NETで開発しています。これは、それ自体がフレームワークであり、Rxはそのままになっているようです。例えば、David Westは、あるシステムのクラスの80％がlibsから来て、20％だけが手作業でコード化され、システム自体に固有であるべきだと提唱しています。私は、これがなぜPythonが成功したのかと考えています。

ケーキの中でRxを使う事実上の現実的な話です。それを振りかけるか、生地にまんべんなく混ぜるのですか？

Answer 1

この性質の質問に対するすべての回答と同様に、 "場合によります"。

何が依存していますか？

• ターゲットコンシューマまたはあなたのライブラリは誰ですか？
• 解決している問題の性質は何ですか？

ターゲットコンシューマが社内、あるいはそれ以上に優れている場合は、好きなことをしてください。真剣に。

他の人があなたのライブラリ（たとえば、公開、Nugetでの生活）を使用する場合は、その他の考慮事項があります。 あなたのライブラリの性質が非同期メソッドの振りかざしであり、Rxがタスクよりも好きである場合、私は実際にタスクを維持することに誤りがあります。あなたがRxに依存するなら、あなたのクライアントもそうです。あなたがクライアントが別のバージョンのRxに依存している別のlibに依存してしまった場合、それは楽しいかもしれません。

あなたのライブラリがデータポイントの真の「ストリーミング」セットを浮上している場合、それらをIObservableとして公開すると便利です。しかし、Rxを内部的に使用していない場合は、Rxの依存関係からエラーが発生します。コールバックパラメータまたは通常の古い.NETイベントメンバーを使用してメソッドを公開できます。消費者がRxを使いたい場合、Observable.CreateはあなたのAPIをRxに簡単に適応させます。