在Unity中解析類型時傳遞構造函數參數：最佳做法

Question

當使用依賴注入來提供在構造函數中使用的參數時，有時需要這樣做。這是在Unity（和其他依賴注入容器）中支持的東西，所以當它試圖創建類型的實例時，它可以在構造函數中提供參數作爲參數。

我的問題是：這種方法是否可取？

內的接口是不可能指定哪些參數的實現類必須有。通過給Unity指定參數，假定實現類具有這些參數，並且將對未來的實現類進行隱式約束。這些約束無法通過接口傳遞。

那麼，這是如何接口本身指定（在.NET）的缺陷，例如。應該可以指定構造函數簽名嗎？或者由於其他的需要，這個功能（能夠提供構造參數）包含在Unity中嗎？

唯一真正可行的方法（對我來說）似乎是使用一個工廠來創建實現類，並做了工廠依賴注入。

我很感激我的問題在這裏可能不是很清楚，所以我會問它略有不同：什麼是應該做在具有需要參數的構造函數的類的依賴注入的最佳方式？

（我不相信這個問題是主觀的，因爲有可能應該是這種類型的依賴注入的單一設計模式。）

編輯：

我要補充一點，我的主要問題是我可以創建一個新的實現類，它具有額外的構造函數參數（其中構造函數參數不是可以通過統一創建的東西）。

Answer 1

IoC容器（比如統一）的職責是與接口的具體實現連接。這意味着你的容器必須知道接口以及如何創建實現接口的對象。使用構造函數注入是完全合法的，也是推薦的方式。當您的應用程序通過Resolve（）方法請求一個接口時，Unity將創建具體的實現。 Unity容器本身是創建對象的工廠，因爲您不想自己實現這些工廠，所以使用Unity。

Answer 2

我不確定你在哪裏得到構造函數注入不適合DI的想法。我認爲真實情況與此相反：構造函數注入是用於實現依賴注入的最常見模式之一 - 我甚至可以說它是最常見的模式，而該視圖當然大多數控制反轉容器（DI容器）使用構造器注入作爲他們的首選機制這一事實支持了這一點。

StructureMap例如有一個核心，爲構造函數注入它會選擇最參數用於解決依賴構造函數的構造非常具體的支持。

你在說什麼使用構造函數注入模式是「我通過指定它們作爲傳入構造函數的參數來移除我的類中的硬編碼依賴項 - 我的類無法在沒有這些依賴項的情況下實例化」。當然，這個聲明的前半部分是DI的本質，但下半場更強調這一點。

依賴關係是應該能夠輕鬆更改的實現細節，提供了一個靈活的，鬆散耦合的解決方案。他們是關於如何，而不是什麼。接口指定了什麼。所以我會說，你在接口中指定依賴關係的建議實際上違背了依賴注入的概念。

至於你關於工廠的陳述 - 這正是IOC容器的意義 - 偉大的大工廠負責解決方案的依賴樹，所以你不需要關心。

編輯

我想，也許你是問要提供非依賴構造函數的參數的情況下，如爲引用實體的ID，或初始狀態枚舉？

我個人沒有看到IOC容器允許這個問題。它仍然是你的階級的初始狀態，因此需要明確表達該狀態的創建規則。這可能意味着您有時需要更多參考您所喜歡的IOC容器，但放棄注射器注入的其他好處並非可怕的情況。

Answer 3

這裏的問題是Unity中InjectionConstructor的定義，比如說Castle.Windsor中的一個。

在Unity中，如果你需要注入一個特定的參數，比如說一個AppSetting，你也被迫提供所有其他參數，從而修復構造函數的簽名。但是，在Castle.Windsor中，它使用您提供的參數，然後使用解析機制以正常方式查找其他參數。

這將有可能通過編寫做了一個「最適合」的方式來使用它的構造函數，而不是默認的貪婪/提供一切這是默認的自定義生成器戰略，引入統一這一點。