有關可擴展性和可測試性的（分層）庫中StructureMap的問題

Question

我們在創建分層庫時使用StructureMap作爲我們的依賴注入（DI）框架。我們的目標是：

• 讓我們在開發和維護庫的時候能夠輕鬆地單元測試類（並使用模擬類而不是真正的依賴關係）。
• 很容易讓圖書館用戶：
  • 通過異體實現一個接口他們和配置要使用的庫的執行，而不是我們自己的自定義庫的行爲。
  • 單元測試他們實現的類（這與我們內部的目標是一樣的，但我們希望它也爲圖書館用戶完成）。

通過分層的圖書館，我們的意思是，我們正在建設兩個DLL`s：

1. 的核心庫。它應該可以在任何.NET應用程序中使用，無論是Console應用程序還是MVC應用程序。
2. WebForms庫。它包含核心庫，還提供WebForms控件，使WebForms用戶的生活更輕鬆。

我們的問題：

1. 我們應該在哪裏調用代碼映射混凝土類核心庫接口？它沒有單一的入口點，有許多類可能首先被實例化。

   目前我們強制用戶在進行任何其他庫調用之前先致電DependencyHandler.Init()。有沒有更好的方法，就像加載DLL後執行的一段代碼一樣，這樣我們就不會強制用戶編寫一行鍋爐代碼？

2. 哪種方法讓圖書館用戶將接口實現更改爲自己的類型？目前，用戶可以通過StructureMap.Configuration.DSL.Registry theRegistry = DependencyHandler.Instance().GetConfiguration()檢索註冊表，然後通過例如theRegistry.For<IFoo>().Use<MyOwnFooImplementation>();更改事情。使用XML會更好嗎？如果是這樣，我們應該在哪裏放置XML？我們選擇編程方法，因爲Visual Studio將能夠爲用戶提供一些幫助。

3. 如果使用上述中的當前方法，則庫用戶必須（至少現在）向StructureMap.DLL以及我們的DLL添加引用。我們是否可以通過使用XML進行依賴設置來消除用戶的負擔？

4. 在我們應該使用的WebForms中是否有一個很好的中央位置，它可以解決問題 for WebForms library DLL？

5. 您如何建議我們爲生產和測試構建物件？

   目前的想法是在必要的所有地方使用DI，以啓用單元測試，我們和我們的用戶需要它，並且允許用戶通過提供自己的實現來更改庫行爲。

   爲了測試事情，我們和庫用戶將不得不創建模擬類來替換我們想要脫離的依賴關係。這個想法是，我們使用正常的配置，但覆蓋我們想要模擬的類，而不是使用它們的正常實現。這是繼續進行的好方法嗎？

Answer 1

需要注意的是，爲了提供從別人可以隔離他們的代碼，你需要確保他們能夠依賴於抽象，而不是具體實現的API是很重要的。也就是說，只要你公開的那些「做東西」的類實現了一個接口（通常是最好的），就繼承了一個定義接口的抽象類，或者讓所有的公共成員都是虛擬的（通常是最糟糕的），我您的API的消費者能夠將我的代碼與具體實現隔離開來。 換句話說，你自己使用IoC容器並不是提供可測試API的關鍵。但是讓你的類非靜態的和抽象的實現是。儘管如此，使用容器還有很多其他的好處。例如，你可能有一個更容易的時間在你自己的API :)

1. 沒有單一的入口點測試的各種類，但用你我的API將實例化一個或幾個類吧？每個類都可以有構造函數，這些構造函數要求客戶提供該類所依賴的抽象的具體實現。爲避免強制客戶端指定要使用的實現，您還可以提供使用默認實現的無參數構造函數。

2. 這取決於，但是從你的方法到簡單的DSL將API連接到配置文件都可以。一般來說，正如我之前所說的，客戶端可能不會對改變你的類所依賴的實現感興趣，只要他們自己可以將自己的代碼與「頂級」類隔離開來。

3. 應用程序開始可能是一個很好的地方。 Web Forms庫可以是HttpModule，或者您可以提供默認的引導捆綁並指示客戶端在global.asax中的應用程序啓動事件中進行所需的任何更改。

4. 聽起來不錯。就像我之前說的，我認爲最重要的是你的類和它們的方法不是靜態的（最好不是單例），並且它們的接口是以抽象的方式定義的，因此人們可以提供其他具體實現來測試。

我可能誤解了一些東西，但我希望我的回答可以幫助至少有一點:)