我的圖書館應該瞭解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嗎？

回答

相關問題