在Presenter类的构造函数中有一长串参数是否正常？

Question

警告首字母缩略词超载即将到来!!!我正在使用MVP被动视图模式和DI进行TDD和DDD。在我编写每个新测试时，我发现自己在依赖于我的演示者类的构造函数之后添加依赖项。大多数是域对象。我正在使用工厂进行依赖注入，但最终我可能会转移到IoC容器。

当使用构造函数注入（与属性注入相关）时，很容易看到依赖项的位置。大量的依赖关系通常表明一个类有太多的责任，但在演示者的情况下，我没有看到如何避免这种情况。

我想过把所有的域对象都包装成一个单独的“Domain”类，它可以作为一个中间人，但我有这种直觉，我只会移动问题而不是修复它。

我错过了什么或这是不可避免的？

Answer 1

通常，方法（构造函数，函数等）的大量参数是代码气味。很难理解所有论点是什么。如果您有大量相同类型的参数，情况尤其如此。他们很容易混淆，这会引入微妙的错误。

重构称为“引入参数对象”。无论这是否真的是一个域对象，它基本上是一个数据传输对象，它最小化传递给方法的参数数量，并为它们提供更多的上下文。

Answer 2

如果我从一开始就需要一些东西，我只在构造函数上使用DI。否则我使用属性并为其他项目延迟加载。对于TDD / DI，只要您可以在需要时注入项目，就不需要将其添加到构造函数中。

我建议始终遵循Demeter法则而不是遵循DI神话，所有内容都需要在构造函数中。 Misko Hevery（Google的敏捷教练）在他的博客http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/

上对此进行了详细描述

Answer 3

拥有Layer Supertype可能不是一个坏主意，但我认为您的代码气味可能表明其他内容。 Geofflane提到了重构模式Introduce Parameter Object。虽然对于这类问题来说这是一个很好的模式，但我并不完全确定这是解决这种情况的方法。

问题：为什么要将Domain Model对象传递给构造函数？

有太多抽象这样的事情。如果你应该能够信任一个坚实的代码层，那就是你的Domain Model。当您处理Customer，Vendor和Product类时，如果它们是您的基本域模型的一部分并且您不一定需要多态性，则不需要引用3个IEntity对象。

我的建议：传递应用程序和域服务。相信你的领域模型。

修改

重新阅读问题，当它不是非常深夜时，我意识到你的“域类”已经是引入参数对象重构，而不是实际上是一个Layer Supertype，正如我在凌晨3点所想的那样。

我也意识到，您可能需要在Presenter之外的应用程序代码中引用Model对象。也许您在将Model对象传递给Presenter之前对其进行了一些初始设置。如果是这种情况，您的“域类”想法可能是最好的。如果有一些初始设置，当移动到IoC时，你会想要在Castle Windsor中查看类似Factory Support的内容。 （其他IoC容器也有类似的概念。）