.NET Framework類的Unity最佳實踐

Question

我剛剛開始使用任何DI / IoC工具集，並且有一個非常基本的問題。 我正在使用Unity，因為我們還將在整個應用程序中使用許多企業庫模塊。

我的問題是關於.NET Framework類的依賴關系。 例如，在我當前正在使用的類之一中，我需要創建DirectoryInfo類。 根據我的理解，DI中的最佳實踐之一是永遠不要使用“ new”關鍵字-因為這會引入硬依賴性。 那么我應該如何獲得一個新的DirectoryInfo？ 將它作為一項添加到容器中，並使容器具有該類的依賴項嗎？ 這似乎在現實生活中是不切實際的，因為我最終將容器配置成字面量地包含了成千上萬個框架類。 我認為這是一個維護噩夢。

Answer 1

我要說的是工程學。 我認為應該傳遞要創建的DirectoryInfo的路徑，或者傳遞某種保存（或為您提供獲取數據）方式的配置存儲庫（或服務）類。

Answer 2

我不會在容器中注冊像DirectoryInfo這樣的低級類-只要在您的應用程序中的某些地方使用new，這實際上不是問題，只要此要求不會“泄漏”到高級類中即可。 因此，在此示例中，直接在類中創建和使用DirectoryInfo可能很有意義，但是容器會將該類的實例注入其依賴項中。

Answer 3

首先，您可以將其視為SystemWrapper庫。 它包裝DirectoryInfo對象，以便您可以對其進行模擬。

接下來，您可以使用Rhino Mocks和SystemWrapper觀看TDD教程 。 您可以在那里看到DI的用法； 但是，該示例未使用任何IoC。

希望能幫助到你。

Answer 4

以我的看法，BCL（基類庫）中的大多數類都是實用程序類，並且除了直接調用圖之外，通常沒有其他依賴項。

DI旨在使調用圖變平，並防止類之間發生大量串擾。 因此，對於BCL聊天情況您無能為力的事實，您不妨接受它們的含義並繼續使用新的...

您不想要的唯一原因是出於測試目的。 您通常不需要測試BCL類，但是您可能希望將BCL類替換為模擬版本，以使其實際上不執行類所能做的任何事情，而只是假裝這樣做。如有必要，SystemWrapper會這樣做。