在.NET框架本身中是否有IObservable的默认实现，或者我必须使用类似Rx的第三方框架？
之所以问这个问题是因为我试图创建一个可重用的组件，需要公开一个类型为IObservable的属性，而我不想将此组件与任何第三方框架捆绑在一起。
编辑：我所说的第三方是指实现不是BCL的一部分。尽管Rx由MS拥有，但它并不是核心.NET框架的一部分。
编辑：我所说的第三方是指实现不是BCL的一部分。尽管Rx由MS拥有，但它并不是核心.NET框架的一部分。
2个回答
3
.NET BCL中没有IObservable<T>的实现。不过，我强烈建议不要自己写这种实现，非常强烈反对。使用Rx框架。如果有政策禁止使用Rx，那么这个政策是非常、非常错误的。如果你自己尝试实现，你的实现几乎肯定会是错的......这很难做到。即便是我在许多投资银行工作时（它们通常是最懦弱的第三方代码），也从未有过不允许使用Rx的愚蠢决策。如果我的建议太含糊或间接了，请原谅。
- James World
1
1我会将
**_REALLY_** 变成全大写并加粗！ - Michael2
我个人认为这是一个很好的问题。OP想要限制他的依赖项，从而创建一个更健壮的库。对此表示赞赏。
然而，目前其他评论/答案都是基于大量经验得出的。实现自己的IObservable<T>/IObserver<T>并不是一个好主意。但我也注意到你没有说你想要这样做。
当前的答案很简单，就是没有BCL中的IObservable<T>/IObserver<T>接口实现。这是微软有意决定的，以便让Rx以比BCL更快的速度发展。这意味着在实际操作中，您需要通过Nuget依赖Rx。为了使您的代码具有任何功能，它至少需要Rx-Linq（因此需要Rx-Core和Rx-Interfaces），其中包含Observable静态类，用于访问Observable.Create、Interval、Empty等。
如果您的组件是UI组件，则可能需要依赖于Rx-Main和Rx-PlatformServices。幸运的是，Rx版本发布的速度现在相当慢，并且他们小心地遵循语义化版本控制，因此次要版本发布不应该破坏您的代码并允许您灵活地依赖Rx。这将使您的客户能够针对新版本的Rx进行定位，如果他们确实出现了，您的库应该仍然可以正常工作。
- Lee Campbell
1
谢谢你的回答。正如你所说，我只想限制依赖关系。但我并没有写自己的实现的意图。 - Rajan
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
- 相关问题
- 3 如何获取IObservable<IObservable<T>>的最新更改事件？
- 13 为什么我不应该实现IObservable<T>？
- 5 将ConcurrentQueue<T>作为IObservable<T>公开？
- 39 从零开始实现IObservable<T>
- 4 将 IObservable<Timestamped<T>> 转换为 IObservable<TimeInterval<T>>。
- 4 将IEnumerable<T>转换为IObservable<T>，并实现最大并行性。
- 3 将一个 IObservable<IEnumerable<T>> 转换为一个 IEnumerable<IObservable<T>>。
- 3 如何将一个 IObservable<IObservable<T>> 转换成一个 IObservable<IEnumerable<T>>？
- 9 为什么Task<T>没有实现IObservable<T>？
- 7 将 IObservable<Task<T>> 转换为保持顺序的 IObservable<T>
IObservable/IObserver的实现。 - LeeIObservable<T>呢？尽管如此，你真的不应该自己编写实现 - 这很难做到正确。Reactive Extensions 团队的成员们花费了多年时间来完善它。如果你不想引用“第三方”框架，你可以只引入你需要的代码 - 毕竟它是开源的。 - Enigmativity