我是否可以在運行時有條件地將接口與Castle Windsor綁定？

Question

我可能在描述這個錯誤，但是這是我的難題，我有一系列接口，例如IBreadcrumbRetriever 。 它們的實現完全不同，這取決於它們在我的網站上的位置，我使用HttpContext.Current.Request.Path來確定它們。

因此，在我的具體類中，我現在有幾個if語句，這些語句確定要返回的項目（為簡單起見，我們說List<string> ）。 這對我來說是一種代碼氣味。

我真正想要的是某種程度上的感覺，我覺得IoC和Castle Windsor可以在這里幫助我，是確定用戶是否在滿足特定條件的情況下訪問了頁面，並將正確的容器綁定到該條件上。 所以我會喜歡

if (HttpContext.Current.Request.Path == some condition)
     IBreadcrumbRetriever is ImplementedBy IsInProductAreaRetriever

這是一個好主意嗎？ 如果是這樣，我該怎么做？ 還是我像面包屑工廠類一樣創建並使用“ .DependsOn(HttpContext.Current.Request.Path) ”擴展名來實現我的工作？

Answer 1

這取決於您的應用程序體系結構是否適合依賴項注入。

我不熟悉Castle Windsor，但總的來說，如果無法在組合根目錄（應用程序啟動）處解決依賴關系，那么注入與當前http上下文兼容的工廠實現就不會有問題。

例如，在ASP.NET應用程序中，您的合成根目錄位於global.asax 。 在那里，您可以將某些IBreadcrumbRetrieverFactory綁定到BreadcrumbRetrieverFactory實現。 new荷蘭國際集團最多不屬於核心框架（和一些是）的一部分類通常是錯過機會DI（和緊耦合）的標志。

IoC容器和DI並不是靈丹妙葯：依賴注入僅僅是一種設計模式（認為構造函數注入，僅分配private readonly字段的構造函數-類型的依賴關系），而IoC容器（所有這些）僅是促進實現的工具具體實現的依賴關系的連接。 考慮到這一點，Castle Windsor不會做窮人的DI所無法完成的任何事情：關鍵在於盡早推動依賴的實例化-即在應用程序啟動時， 撰寫root 。

當依賴項是“動態的”時，例如，當有邏輯確定ISmurf的實現是應該是HappySmurf還是GrumpySmurf ，最好的辦法是恕我直言，注入一個ISmurfFactory依賴項而不是ISmurf ，並推動工廠的連接到合成根。