設計 - 依賴地獄解決方案？

我們使用MVC體系結構和由BLL和DAL組成的模型。設計 - 依賴地獄解決方案？

所以我們爲我們的系統開發「模塊」，並且我正在實現的特定模塊使用了很多相同的依賴關係。一類尤其有20個依賴關係。目前默認的構造函數是創建一個默認的具體實現，我們還有第二個構造函數[第一個使用]允許注入自己的依賴關係（即測試）。

20構造函數參數看起來像一個非常討厭代碼味道。其他討厭的一點就是經常在我開始添加常用的功能，我需要去添加構造函數代碼和領域，各個階級往往一遍又一遍地重複着同樣類型的代碼。

IoC容器似乎是一個自然的解決方案，但問題是我能走多遠？我是否包含DAL依賴項和BLL依賴項？那麼「helper」或「service」依賴關係呢？看起來在某個時候，我只是重新創建了「命名空間」結構，並且能夠像靜態類一樣引用我的類，在這一點上，我懷疑我實際獲得的是什麼。

我無法通過這個想法。有沒有人有一個優雅的解決方案或建議？

來源

2011-10-27 Joshua Enfield

「我很難考慮這個問題」。看看這個教程：https：//github.com/ninject/ninject/wiki –

切線相關：這裏是我寫的另一個關於減少類的依賴關係的問題的答案。 http://stackoverflow.com/questions/5601920/what-are-your-best-practices-when-using-an-mvc-based-web-framework/5602212#5602212 – Domenic

如果你去IoC路線（我推薦），我會包括你的所有依賴在容器中。

好處是，您無需擔心創建這些依賴關係，即使這些依賴關係存在很多圖層深度。

例如，ClassA在構造函數中需要4個其他類，每個類都需要兩個其他類，每個類都至少需要一個DAL引用。

在這種情況下，您只需在最高層（「組合根」）中引用IoC（可能是您的UI）並說「給我一個對象A的實例」，然後IoC將自動實例化其他20個實例，以獲取構建對象圖所需的各種依賴關係。

你的類不再需要擔心如何創建它們的依賴，如果他們需要的東西，他們只是把它貼在構造和的IoC將確保它得到它。

我也會評論說，即使您使用的是IoC，在一個類中的20個依賴關係也是確定的代碼氣味。它通常表明班級做得太多，違反了單一責任原則。

來源

2011-10-27 23:01:41

+1 - 強烈同意，國際奧委會是顯而易見的（原諒MVC雙關語），也適用於「自動」這個詞。 – Reddog

+1表示違反SRP。絕對是一個好主意，看看設計。 –

設計 - 依賴地獄解決方案？

回答

相關問題