我們的團隊一直在構建一個DDD應用程序,該應用程序具有構建爲系統「API」的強烈定義的應用程序服務層。它處理從領域和基礎設施一起拉取所有東西以完成通用任務。它只使用DTO作爲輸入/輸出,因此域永遠不會暴露在該層之外。我應該從UI中抽象一個IOC容器的配置嗎?
現在我們想要添加一個依賴注入容器,我們面臨一些艱難的選擇。我們有兩個使用應用程序服務完成工作的客戶端應用程序:一個MVC 2應用程序和一個Windows服務應用程序。傳統上,使依賴注入工作的所有配置代碼都放在mvc項目中的global.asax文件中,我已經看到了很多示例。問題在於國際奧委會註冊代碼然後在Windows服務中被複制,併爲該平臺稍作修改。
我的問題是,DI需要客戶端應用程序知道要註冊什麼以及如何,這還需要客戶端應用程序引用域和基礎結構層。具有應用程序服務層的整個想法是,這是客戶應該知道和談論的唯一事情。我建議的解決方案是在我的應用程序服務層創建一個「依賴服務」,客戶端只需調用一次,它會配置DI容器,因爲它知道需要什麼。它也有方法允許客戶端應用程序註冊其自己的附加依賴項。例如,MVC項目將註冊其控制器工廠,並且Windows服務將註冊其啓動類。我想知道這是否不常見,或者如果我在這個想法上走錯了路。有沒有其他人遇到過這個問題?
如何註冊網絡特定類型,例如,這種方式? IoCConfigurator是否需要知道並被綁定到所有不同的可能執行環境?如果您需要在Web主機下的容器中註冊MVC控制器,您可能也不想將它們註冊(或者甚至部署程序集)到服務進程主機。 – 2010-12-07 22:36:13
這取決於我的項目涉及哪個部分。如果我在我的DomainModel項目中需要IoC,那麼我將在此項目中爲此特殊依賴項創建一個IoCConfigurator。如果我在我的WebUI MVC項目中也需要IoC,我也會爲這個項目創建一個IoCConfigurator。我儘量讓項目儘可能鬆散。例如,當我需要WebService項目中的DomainModel程序集時,我不會手動處理IoC配置。我假設在這個程序集中有特定依賴關係的配置器。 – Mariusz 2010-12-08 08:04:23