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

Question

當使用依賴注入來提供在構造函數中使用的參數時，有時是必要的。 這是Unity（以及其他依賴注入容器）支持的內容，因此當它嘗試創建該類型的實例時，它可以將您的參數作為參數提供給構造函數。

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

在接口內，無法指定實現類必須具有的參數。 通過為Unity指定參數，您假設實現類具有這些參數，並且您將對未來的實現類放置隱式約束。 這些約束不能通過接口傳遞。

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

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

我很感激我的問題可能不太清楚，所以我會稍微區別一點：在具有構造函數需要參數的類上進行依賴注入的最佳方法是什么？

（我不認為這個問題是主觀的，因為這種類型的依賴注入可能只有一個設計模式。）

編輯：

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

Answer 1

我不知道你在哪里認為構造函數注入不適合DI。 我想說，真正的情況是相反：構造函數注入是用來實現依賴注入最常見的模式之一-我會去遠的話說，這是最常見的模式，這種觀點肯定是由於大多數控制反轉容器（DI容器）使用構造函數注入作為其首選機制這一事實得到了支持。

例如，StructureMap具有核心的，非常具體的構造函數注入支持，它將選擇具有最多參數的構造函數作為用於依賴項解析的構造函數。

你通過使用構造函數注入模式說的是“我通過將它們指定為傳遞給構造函數的參數來刪除我的類中的硬編碼依賴項 - 我的類在沒有這些依賴項的情況下無法實例化”。 當然，該聲明的前半部分是DI的本質，但是后半部分更強調了這一點。

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

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

編輯

我想也許您在詢問是否要提供非依賴構造函數參數的情況，例如引用實體的id或初始狀態枚舉？

我個人認為IOC容器沒有問題。 它仍然是你的類的初始狀態，因此需要明確表達創建該狀態的規則。 這可能意味着您有時需要更多您可能喜歡的IOC容器的引用，但放棄counstructor注入的其他好處並不是一個非常可怕的情況。

Answer 2

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

Answer 3

這里的問題是Unity中的InjectionConstructor的定義vs Castle.Windsor中的定義。

在Unity中，如果需要注入特定參數，比如AppSetting，您還必須提供所有其他參數，從而修復構造函數的簽名。 但是，在Castle.Windsor中，它采用您提供的參數，然后使用解析機制以正常方式定位其他參數。

可以通過編寫一個自定義構建器策略將其引入Unity，該策略使用構造函數使用“最適合”的方法而不是默認的貪婪/提供默認的所有內容。