我读了整个帖子，两遍，我认为人们是根据他们所知道的来回应，而不是根据被问到的问题。

JP最初的问题看起来像是通过发送一个解析器来构造对象，然后是一堆类，但我们假设这些类/对象本身就是服务，可以进行注入。如果不是呢?

JP，如果您希望利用DI并希望将注入与上下文数据混合在一起，那么这些模式(或假定的“反模式”)都没有专门解决这个问题。它实际上可以归结为使用一个包，它将支持你在这样的努力。

Container.GetSevice<MyClass>(someObject1, someObject2)

．.． 很少支持这种格式。我相信编写这种支持程序的难度，再加上与实现相关的糟糕性能，使得它对开源开发人员没有吸引力。

但这是应该做到的，因为我应该能够为MyClass'es创建和注册一个工厂，并且该工厂应该能够接收数据/输入，而不是仅仅为了传递数据而被推为“服务”。如果“反模式”是消极的结果，那么强制存在用于传递数据/模型的人工服务类型肯定是消极的(就像将类打包到容器中一样)。同样的本能也适用)。

不过，有一些框架可能会有所帮助，尽管它们看起来有点难看。例如，Ninject:

在构造函数中使用Ninject和附加参数创建一个实例

这是针对。net的，很流行，但仍然没有达到应有的干净程度，但我相信无论你选择使用什么语言，都有一些东西。

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

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

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

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

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

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

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

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

我遇到过一个类似的问题，关于基于构造函数的依赖注入，以及传递所有依赖是多么复杂。

我过去使用的方法之一是使用服务层来使用应用程序外观模式。这将有一个粗糙的API。如果此服务依赖于存储库，则它将使用私有属性的setter注入。这需要创建一个抽象工厂，并将创建存储库的逻辑移到工厂中。

详细的代码和解释可以在这里找到

复杂服务层IoC的最佳实践