創建使用.NET名稱空間的庫的最佳實踐

Question

編寫定義依賴於另一個庫的接口的庫是不好的做法嗎？

我知道緊密耦合是不好的，但是在使用.NET類時，這仍然適用嗎？

例如，在.NET中，如果我有一個返回Color對象的庫，則它將強制依賴System.Drawing使用我的庫的任何內容。 我會在自己的庫中創建自己的Color-type類更好嗎？

Answer 1

我區分易變和穩定依賴項 。

通常，Color看起來像是穩定依賴項，因為它已經存在於BCL中，本質上是確定性的，不涉及任何資源密集型的進程外通信，也不依賴於其運行的特定設置-時間環境。

這里唯一要考慮的是，涉及Color時，BCL中有多個這樣的類，因此請確保您確實要使用API​​定位Windows Forms應用程序，因為WPF有其自己的Color定義。

如果您只需要Color即可將用戶界面的某些部分繪制成某種顏色，則內置的Color類可能很好，但是如果Color是您的域模型中的主要概念，則您需要定位不同的UI（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具有客戶端配置文件安裝程序，這基本上意味着，如果您使用此安裝程序，它將僅安裝預期在客戶端上使用的內容。 我個人認為這對Microsoft而言不是一個好主意，因為它只會增加不必要的復雜性，從而節省少量的下載時間。