IOC（StructureMap）

通過我的（可能是微薄的）理解，在你的控制器的方法的中間這樣做/演講被認爲是不好的做法，因爲它創建StructureMap和您的主持人之間的依賴關係最佳實踐：IOC（StructureMap）

void Override() { 
    ICommentForOverrideGetter comm = StructureMap.ObjectFactory.GetInstance<ICommentForOverrideGetter>();

由於這種依賴性應通過構造函數注入演示者，並使用IoC容器將其連接起來。在這種情況下，儘管每次運行此方法時我的代碼都需要ICommentForOverrideGetter的全新副本。這是上述最佳實踐的例外，還是我應該重新考慮我的架構的情況？

來源

2010-09-20 Adam Rackis

據說，有計算機科學沒有什麼問題不能由一個間接多個層次來解決：

如果你只是不想在你的演講的依賴，注入一個工廠接口，真正的實現可以做新的CommentForOverrideGetter或其他。

編輯：

「我沒有問題，忽略了最佳實踐的時候我覺得複雜/效益比過高」：我也不知道，但我在評論中說，我不喜歡依賴難在代碼中的IoC容器上我想單元測試，演示者就是這種情況。

根據你的ICommentForOverrideGetter做什麼，你也可以使用一個簡單的CommentForOverrideGetter.CreateNew（），但是如果你需要每次調用一個新的實例，我會懷疑至少有某種與創建相關的邏輯？或者它是一種有狀態的「服務」？

來源

2010-09-20 15:17:56 Maxem

我絕對喜歡這種說法（來自David Wheeler）。我知道我可以做到這一點，但男孩，這似乎太簡單的東西太多的開銷。 IoC容器是否應該像您所描述的那樣消除對工廠的需求？ – 2010-09-20 15:21:16

IoC電話並不是特別困擾我，我只是想了解更多關於IoC最佳做法。當我認爲複雜度/效益比太高時，我毫無疑問地忽視了最佳實踐，我只是想確保沒有其他東西丟失。 – 2010-09-20 15:22:57

個人而言，我只是不希望在演示者中對IoC容器產生嚴重依賴（或者更普遍：我想單元測試的類）。 – Maxem 2010-09-20 15:25:01

如果您堅持在您的方法中執行服務位置，您至少應該將容器注入控制器，以便您可以消除靜態方法調用。添加StructureMap.IContainer類型的構造函數參數並將其存儲在字段變量中。 StructureMap將注入適當的容器。然後，您可以調用該容器上的GetInstance（），而不是ObjectFactory。

來源

2010-09-20 18:42:06

IOC（StructureMap）

回答

相關問題