.NET Framework 中 IObservable<T> 的默认实现答案

【问题标题】：Default Implementation of IObservable<T> in .NET Framework.NET Framework 中 IObservable<T> 的默认实现
【发布时间】：2016-03-08 16:42:47
【问题描述】：

.NET 框架本身是否有 IObservable 的默认实现，或者我必须使用 Rx 等 3rd 方框架？我问的原因是我正在尝试创建一个需要公开 IObservable 类型的属性的可重用组件，并且我不想将此组件与任何此类 3rd 方框架绑定。

编辑：我所说的第三部分的意思是实现不是 BCL 的一部分。尽管 Rx 归 MS 所有，但它不是核心 .NET 框架的一部分

【问题讨论】：

好吧，如果您不想将其与第 3 方框架绑定，请不要。也就是说，Rx 无论如何都不是第三方 :)
@DStanley - 是的，但在 BCL 中根本没有实现 IObservable/IObserver。
为什么你想要一个IObservable<T> 却没有 Rx 中所有好的操作符？尽管如此，你真的不应该编写自己的实现——很难做到正确。 Reactive Extensions 团队的人花了好几年的时间才把它做好。如果您不想引用“第三方”框架，您可以引入您需要的代码——毕竟它是开源的。

标签： .net system.reactive

【解决方案1】：

.NET BCL 中没有IObservable<T> 的实现。也就是说，我强烈建议不要自己编写。就像，真的强烈。一百万次。 使用 Rx 框架。如果有一项政策阻止您这样做，那是非常非常错误的。如果您自己尝试过，几乎可以肯定您的实现是这样的......看起来很难做到正确。 在我工作过的众多投资银行中，没有一家（在 3rd 方代码方面通常是最大的三色堇）愚蠢到不让 Rx 被使用。这个建议有点过于单薄、含糊和间接，请见谅。

【讨论】：

我会将所有大写字母 **_REALLY_** 也加粗！

【解决方案2】：

我个人认为这是一个很好的问题。 OP 希望限制他的依赖关系，从而创建一个更健壮的库。对此表示敬意。

但就目前而言，其他 cmets/answers 来自大量经验。实现自己的IObservable<T>/IObserver<T> 不是一个好主意。但我也注意到你并没有说你想要。

当前的答案很简单，不 - BCL 中没有 IObservable<T> / IObserver<T> 接口的实现。这是 MS 的一个有意识的决定，允许 Rx 以比 BCL 更快的节奏发展。这意味着实际上您需要通过 Nuget 依赖 Rx。要使您的代码真正具有任何功能，它至少需要Rx-Linq（因此需要Rx-Core 和Rx-Interfaces），它具有Observable 静态类，用于访问Observable.Create、Interval、Empty 等。

如果您的组件是 UI 组件，那么您可能需要依赖于 Rx-Main 和 Rx-PlatformServices。幸运的是，现在 Rx 发布的节奏很慢，并且他们小心地遵循语义版本控制，因此次要版本的发布不应该破坏你的代码，并允许你对 Rx 有灵活的依赖关系。如果新版本的 Rx 确实出现了，这将使您的客户能够以新版本为目标，并且您的 lib 应该仍然可以正常工作。

【讨论】：

感谢您的回答。正如你所说，我只想限制依赖关系。但我没有任何打算编写自己的实现。