我的图书馆应该了解Reactive Extensions吗？

我对.NET的Reactive Extensions越来越感兴趣。由于我的应用程序涉及数据采集系统，因此很可能甚至是我的域库的核心类和概念都可以使用Rx概念。我的图书馆应该了解Reactive Extensions吗？

我的疑问是：我应该用Rx类型和接口“污染”我的域模型吗？或者我应该保持它“干净”，仅在客户端代码中使用Rx？

一方面，清洁架构支持者（主要是Bob叔叔）主张“你不应该依赖框架”，这是有道理的。另一方面，我已经在.NET中开发了，.NET本身就是一个框架，而Rx似乎已经停滞不前。例如，David West主张系统中80％的类应该来自库，只有20％应该是手工编码的，并且是系统自身特有的。我相信这就是为什么Python也是如此成功的原因，“电池包括”的方法，图书馆的方式。

因此，务实地说，这是在你的蛋糕中使用Rx的事实上的方式：你撒上去，还是混合到面团？

来源

2017-01-09 heltonbiker

有趣，但可能是自以为是的。我不会在核心库中公开暴露RX（或RX依赖类型），也许会在一个单独的库中提供一堆扩展方法，以允许用户轻松地缩小差距（以'ToObservable'可用的扩展方法'任务'） – spender

@spender感谢您的反馈。不会“在一个单独的库中提供一堆扩展方法”，这完全是Rx即将开始的事情？这就是为什么我问，看起来我没有必要依靠Rx，它似乎已被有意地作为扩展库完成了，可能呢？ – heltonbiker

对于这种性质的问题的所有答案; “这取决于”。

它取决于什么？

谁是目标消费者或您的图书馆？
你正在解决的问题的性质是什么？

如果你的目标消费者是内在的，甚至更好，只是你，然后做你喜欢的。认真。

但是，如果其他人会使用你的图书馆（例如公众，住在Nuget），那么你有其他的考虑。如果你的库的性质是Async方法的泛滥，并且你刚好喜欢Rx而不是Task，那么我实际上会在保留Task时犯错。如果你依赖于Rx，那么你的客户也是如此。如果你的客户端碰巧依赖于另一个依赖于不同版本Rx的lib，那么这很有趣。

但是，如果您的库正在显示一个真正的“流式”数据点集合，那么将这些集合暴露为IObservable会很有用。如果你不在内部使用Rx，那么，我会错过Rx依赖。您可以公开带有回调参数的方法或正常的旧.NET事件成员。如果消费者想要使用Rx，那么Observable.Create将很容易将您的API调整为Rx。

来源

2017-01-10 06:36:12

感谢您的回答！我想我正在采用第二种方法（Rx一路），因为我的核心库实际上“正在显示一个真正的”流式“数据点集”，我是一个应用程序开发人员（与图书馆开发人员相反），并且考虑到我期望在表现力和线程安全性方面取得的巨大影响，我已经在使用如此多的NuGet软件包，以至于很难做到这一点。再次感谢！ – heltonbiker

我的图书馆应该了解Reactive Extensions吗？

回答

相关问题