如何避免依赖注入构造函数的疯狂？

Question

如何避免依赖注入构造函数的疯狂？

我发现我的构造器开始像这样：

public MyClass(Container con, SomeClass1 obj1, SomeClass2, obj2.... )

随着参数列表的不断增加。既然“容器”是我的依赖注入容器，为什么我不能这样做：

public MyClass(Container con)

每节课？缺点是什么？如果我这样做，感觉就像在使用一种美化的静电。请分享你对国际奥委会和依赖注入疯狂的想法。

Answer 1

如果您使用容器作为服务定位器，您是正确的，它或多或少是一个美化的静态工厂。有很多原因我认为这是一种反模式。.Constructor注入的好处之一是它违反了单一责任原则显而易见。当这种情况发生时，是时候对外观服务的重构..简而言之，创建一个新的、更多的粗粒接口，它隐藏了当前需要的一些或所有细粒度依赖项之间的交互。

Answer 2

我认为您的类构造函数不应该引用IoC容器期间。这表示了类与容器之间的一种不必要的依赖(IoC试图避免的依赖类型)。

Answer 3

传递参数的困难不是问题。问题是你的课做得太多了，应该更多地分解。依赖注入可以作为类变得太大的早期警告，特别是因为传递所有依赖项的痛苦越来越大