一个方法的参数太多是一个暗示(不一定)，你的方法太大/有太多的责任。

此外，在同一方法中使用的参数(可能)具有很高的内聚性——>值得考虑将它们放在一个类中——>只必须传递一个参数。

我不认为你的类构造函数应该引用你的IOC容器期。这代表了类和容器之间不必要的依赖关系(IOC试图避免的依赖类型!)

你是对的，如果你使用容器作为一个服务定位器，它或多或少是一个美化的静态工厂。出于很多原因，我认为这是一种反模式(请参阅我书中的节选)。

构造函数注入的一个好处是，它使违反单一责任原则的行为变得非常明显。

当这种情况发生时，是时候重构到Facade Services了。简而言之，创建一个新的、更粗粒度的接口，隐藏当前所需的一些或所有细粒度依赖项之间的交互。

注入容器是一个您最终会后悔的快捷方式。

过度注入不是问题，它通常是其他结构缺陷的症状，最明显的是关注点分离。 这不是一个问题，而是有很多来源，让这个问题变得如此难以解决的是，你将不得不处理所有的问题，有时是在同一时间(想象解开意大利面条)。

这里是一个不完整的注意事项列表

糟糕的域设计(聚合根目录....等)

关注点分离差(服务组合，命令，查询)参见CQRS和事件来源。

或绘图器(要小心，这些东西会给你带来麻烦)

视图模型和其他DTO(永远不要重用它们，并尽量将它们保持在最小值!!!!)

一个方法的参数太多是一个暗示(不一定)，你的方法太大/有太多的责任。

此外，在同一方法中使用的参数(可能)具有很高的内聚性——>值得考虑将它们放在一个类中——>只必须传递一个参数。

传入参数的困难不是问题。问题是你的类做的太多了，应该再分解一些。

依赖注入可以作为类变得太大的早期警告，特别是因为传递所有依赖的痛苦正在增加。