警告首字母缩写词超载逼近!!!我正在做一个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容器也有类似的概念。）