我对.NET的Reactive Extensions越来越感兴趣。由于我的应用程序涉及数据采集系统，因此即使是我的域库的核心类和概念，也可以使用Rx概念。
我的疑问是：我应该用Rx类型和接口“污染”我的域模型吗？或者我应该保持“干净”，仅在客户端代码中使用Rx？
一方面，Clean Architecture的支持者（鲍勃大叔）主张“你不应该依赖于框架”，这是有道理的。
另一方面，我已经开发了.NET，它本身就是一个框架，Rx似乎已经存在。例如，David West主张系统中80％的类应该来自libs，只有大约20％的类应该是手工编码的，并且特定于系统本身。我相信这就是为什么Python也是如此成功的原因，即“包含电池”的方法，在图书馆方面。
所以，实际上，这是在你的蛋糕中使用Rx的事实上的方式：你把它撒在上面，或者将它混合到面团中吗？
答案 0 :(得分：4)
与所有这些问题的答案一样; “这取决于”。
它依赖于什么？
如果您的目标消费者是内部消费者，甚至更好，只有您，那么就做您喜欢的事。严重。
但是，如果其他人将使用您的图书馆（例如公共图书，生活在Nuget上），那么您还有其他注意事项。 如果您的库的性质是一堆Async方法，并且您恰好喜欢Rx而不是Task，那么我实际上会错误地保留Task。如果您依赖Rx，那么您的客户也将如此。如果你的客户端碰巧依赖于另一个依赖于不同版本的Rx的lib，那么这很有趣。
但是，如果您的库正在出现一组真正的“流式”数据点，那么将它们作为IObservable公开可能会很有用。但是如果你不在内部使用Rx，那么我将不再使用Rx依赖。您可以使用回调参数或普通的旧.NET事件成员公开方法。如果消费者想要使用Rx，那么Observable.Create将很容易使您的API适应Rx。