什麼是依賴注入用戶輸入的最佳策略？

Question

我已經使用了大量的依賴注入，但我想獲得關於如何在運行時處理來自用戶的信息的輸入。

我有一個類連接到COM端口。我允許用戶選擇com端口號。現在，我將該com參數作爲構造函數參數。理由是，如果沒有這些信息，類就不能運行，並且它是特定於實現的（這個類的模擬版本不需要com端口）。

另一種方法是爲具有「開始」方法，它採用在com端口，或具有設置com端口的屬性。這使得它與IoC容器非常兼容，但從類的角度來看它並不一定有意義。

好像邏輯路徑的衝突與依賴注入的設計，但它是因爲我的UI是針對特定類型的類中獲取信息。

其他替代方案將包括使用IoC容器，讓我通過額外的構造函數的參數，或者只是構建我需要在頂層的類，而無需使用依賴注入。

是否有這類問題的一個普遍接受的標準模式？

Answer 1

這裏有兩條路可以走，根據您的需求。

1線的UI直接向您的具體類

這是最簡單的選擇，但很多時候完全可以接受的。雖然您可能有一個帶有大量界面和使用DI的域模型，但UI構成了對象圖的組合根，並且您可以在此處簡單連接具體的類，包括您需要的端口號參數。

的好處是，這種方式很簡單，易於理解和執行。

不足之處是你的靈活性降低。您將無法任意替換一個實現與另一個實現（但是，然後再次，您可能不需要這種靈活性）。

即使將UI鎖定到具體的實現，這並不意味着域模型本身不會在其他應用程序中重複使用。

2.添加一個抽象工廠

的另一種選擇是增加一個間接的另一層。您可以不使用UI直接創建類，而是使用Abstract Factory來創建實例。

工廠的Create方法可以將端口號作爲輸入，所以這個抽象最好在UI子層中。

public abstract class MyFactory 
{ 
    public abstract IMyInterface Create(int portNumber); 
} 

然後，您可以讓您的DI容器線了這個工廠使用的端口號，並將其作爲一個構造函數參數傳送給真正實施的實現。其他工廠實現可能會忽略該參數。

這種方法的優點是你不會污染你的API（或你的具體實現），並且你仍然具有編程接口給你的靈活性。

缺點是它增加了另一個間接層。

Answer 2

大多數IoC容器都有某種形式的Constructor Injection，這將允許您的IoC容器將模擬COM端口傳遞到您的類中進行單元測試。這似乎是最乾淨的解決方案。

我會避免添加一個「開始」方法等。它的更好的做法是（如果可能的話）總是讓您的類處於有效狀態，並且使用start方法切換到無參數構造函數會使您的類在這些類之間無效調用。這樣做是爲了測試（讓它更好），讓測試更加困難。