警告首字母縮寫詞超載逼近!!!我正在做一個MVP被動查看模式和DI的TDD和DDD。當我編寫每個新測試時，我發現自己在依賴關係之後向我的演示者類的構造函數添加了依賴項。大多數是域對象。我使用工廠進行依賴注入，但我最終可能會轉向IoC容器。在Presenter類的構造函數中有一長串參數是否正常？
當使用構造函數注入（如同屬性注入一樣）時，很容易看到你的依賴關係在哪裏。大量的依賴關係通常表明一個班級有太多的責任，但對於演講者來說，我沒有看到如何避免這種情況。
我想過把所有的域對象包裝成一個單獨的「域」類，它可以充當中間人，但我有這種直覺，我只是在移動問題而不是修復它。
我錯過了什麼，或者這是不可避免的？
我只在構造函數上使用DI，如果我需要一些東西從一開始就在那裏。否則，我使用屬性並延遲加載其他項目。對於TDD/DI，只要您可以在需要時注入該項目，則無需將其添加到構造函數中。
我推薦始終遵循德米特法則，而不是遵循構造函數中所有需要的DI神話。 Misko Hevery（Google的敏捷教練）在他的博客中描述得很好http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/
通常一個方法（構造函數，函數等）的大量參數是代碼味道。可能很難理解所有的論點。如果您有大量相同類型的參數，則尤其如此。他們很容易混淆，這可能會引入微妙的錯誤。
重構被稱爲「介紹參數對象」。無論這是否是一個域對象，它基本上都是一個數據傳輸對象，它將傳遞給方法的參數數量減到最少，併爲它們提供更多的上下文。
有一個Layer Supertype可能不是一個壞主意，但我認爲你的代碼味道可能表明別的東西。 Geofflane提到了重構模式，Introduce Parameter Object。雖然對於這類問題來說這是一個很好的模式，但我不完全相信這是應對這種情況的方法。
問：爲什麼要將Domain Model對象傳遞給構造函數？
有這樣的事情，太多抽象。如果您應該可以信任一層可靠的代碼，那就是您的Domain Model。如果客戶，供應商和產品類屬於您的基本域模型的一部分，並且您不一定需要多態性，則不需要引用3個IEntity對象。
我的建議：通過申請和域名服務。信任你的域模型。
編輯：
重讀的問題時，它不是可怕的深夜，我知道你的「域類」已經是引入參數對象重構和不是，事實上，一個圖層父類型，如我在凌晨3點想到。
我也意識到，也許你需要在Presenter之外的應用程序代碼中引用Model對象。也許您在將模型對象傳遞給Presenter之前先進行一些初始設置。如果是這種情況，您的「域名類」的想法可能是最好的。如果有初始設置，當轉移到IoC時，您需要在Castle Windsor中看到類似Factory Support的東西。 （其他IoC容器也有類似的概念。）