創建使用.NET命名空間的庫的最佳做法

Question

編寫定義依賴於其他庫的接口的庫是不好的做法嗎？

我知道緊密耦合是不好的，但是這仍然適用於使用.NET類嗎？例如，在.NET中，如果我有一個返回Color對象的庫，它將強制在使用我的庫的任何東西上依賴System.Drawing。我會更好地在我的庫中創建自己的Color類型類嗎？

Answer 1

我Volatile和穩定依賴之間進行區分。

一般來說，Color看起來像一個穩定的依賴關係，因爲它已經在BCL中，它本質上是確定性的，不涉及任何資源密集型的進程外通信，也不依賴於特定的設置它的運行環境。

這裏唯一需要考慮的是，當涉及到Color時，BCL中有多個這樣的類，因此請確保您確實意味着僅使用您的API定位Windows窗體應用程序，因爲WPF有其自己的定義的顏色。

如果您只需要顏色以某種顏色繪製UI部分，那麼內置的Color類可能很好，但如果Color是您的Domain Model中的主要概念，並且您需要定位不同的用戶界面（WPF，Windows Forms，Web）通過定義自己的抽象可能會更好。

在這樣一個更高級的情況下，您可以隨後在抽象中創建適配器和映射器，以彌合抽象和具體Color類之間的差距。

Answer 2

如果它是一個標準的.NET庫，我不會擔心它。沒有理由從一個類映射到另一個類......如果System.Color在下一個.NET版本中發生了變化，該怎麼辦？您必須更改您的映射代碼，並且可能必須相應地檢測版本和映射。這是一個真正的痛苦。

Answer 3

在我的所有庫中，我只返回依賴庫中事物的對象。

我會問自己，爲什麼我要編寫一個依賴另一個不隱含的命名空間的庫。這似乎違背了整個「封裝」的概念。

所以，只要脫離我自己的推理和OOP知識，我會說你正在迴歸自己的​​非依賴對象的正確軌道。

Answer 4

你提出了一個很好的問題。答案是：這取決於。在標準庫永遠可用的情況下，那很好;核心庫一直引用不同的.DLL。

在第三方庫的情況下遇到問題。如果別的東西做了你想要的東西，推出自己的產品並不總是一個好主意，但是你依賴於另一個庫，這對用戶來說是一個後勤問題。

這裏沒有正確的答案，你只需要選擇對你的項目最有意義的東西。試着儘可能分離，是的，但有時候你只需要擁抱並完成工作。

Answer 5

這取決於您對班級的使用情況。

如果您需要從Color類的實例中獲取系統Color類的實例（例如，如果您繪製到Windows窗體），那麼最好使用System類 - 它爲您節省了努力不得不在兩種類型之間進行轉換，併爲您提供了可以免費使用Color類的所有「特性」的優點（例如內置常量「紅色」，「黑色」，「綠色」等）。 ..

如果另一方面你只是簡單地使用任意RGB值（可能用於科學計算）並且從不需要需要轉換爲System.Color的實例，那麼創建自己的類可能是有意義的。

很可能你最好使用System.Color類 - 是封裝和所有這是一個好主意，但不以犧牲您大量時間爲代價！

Answer 6

你不應該擔心在.NET核心庫中使用任何東西。如果沒有它，你就不會在很遠的地方編寫DLL。唯一可能要小心的地方是System.Web命名空間，因爲我相信.NET 4有一個客戶端配置文件安裝程序，這基本上意味着如果您使用此安裝程序，它將只安裝預期在客戶端上使用的東西。我個人認爲這對微軟的Part來說是一個壞主意，因爲它只是增加了不必要的複雜功能，可以節省少量的下載時間。