警告首字母缩略词超载即将来临！！！我正在使用 MVP 被动视图模式和 DI 进行 TDD 和 DDD。当我编写每个新测试时，我发现自己在依赖项之后向我的演示者类的构造函数添加依赖项。大多数是域对象。尽管我最终可能会迁移到 IoC 容器，但我正在使用工厂进行依赖注入。
当使用构造函数注入（与属性注入相反）时，很容易看到你的依赖项在哪里。大量的依赖通常表明一个类有太多的责任，但在演示者的情况下，我看不出如何避免这种情况。
我曾想过将所有域对象包装到一个“域”类中，该类将充当中间人，但我有这种直觉，我只是在移动问题而不是修复它。
我错过了什么还是这是不可避免的？
通常，方法（构造函数、函数等）的大量参数是代码异味。很难理解所有论点是什么。如果您有大量相同类型的参数，情况尤其如此。他们很容易感到困惑，这可能会引入微妙的错误。
重构称为“引入参数对象”。不管它是否真的是一个领域对象，它基本上是一个数据传输对象，它最大限度地减少传递给方法的参数数量并为它们提供更多上下文。
如果我需要从一开始就在那里，我只在构造函数上使用 DI。否则我使用属性并延迟加载其他项目。对于 TDD/DI，只要您可以在需要时注入项目，就不需要将其添加到构造函数中。
我建议始终遵循得墨忒耳法则，而不是遵循 DI 神话中的一切都需要在构造函数中。Misko Hevery（Google 的敏捷教练）在他的博客http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/上很好地描述了它
拥有层超类型可能不是一个坏主意，但我认为您的代码气味可能表明其他东西。Geofflane 提到了重构模式Introduce Parameter Object。虽然这是解决这类问题的一个很好的模式，但我不完全确定这是解决这种情况的方法。
问题：为什么要将域模型对象传递给构造函数？
有太多抽象的东西。如果您应该能够信任一层可靠的代码，那就是您的Domain Model。在处理 Customer、Vendor 和 Product 类时，如果它们是基本域模型的一部分并且您不一定需要多态性，则不需要引用 3 个 IEntity 对象。
我的建议：传递应用程序和域服务。相信你的领域模型。
编辑：
当它不是很晚的时候重新阅读这个问题，我意识到你的“域类”已经是 Introduce Parameter Object 重构而不是，事实上，一个层超类型，就像我在凌晨 3 点想的那样。
我还意识到，也许您需要在 Presenter 之外的应用程序代码中引用模型对象。在将模型对象传递给 Presenter 之前，您可能正在对它们进行一些初始设置。如果是这种情况，您的“域类”想法可能是最好的。如果有一些初始设置，当迁移到 IoC 时，您会想要查看诸如温莎城堡中的工厂支持之类的东西。（其他 IoC 容器也有类似的概念。）