这是一个非常简单的问题。我正在使用IoC容器在根级别注册密钥依赖。对于其余的依赖项，我使用构造函数注入。。
解决同一应用程序级别的服务之间依赖关系的最佳做法是什么？
我可以使用IoC容器作为服务定位器，但我同意将服务定位器解释为反模式(http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/)我同意IoC容器应该专注于模块化和组合根。
另一种选择是创建定位器的显式版本，在那里我可以显式定义依赖项，但现在我将违反打开-关闭原则，因为我需要为未来创建的每个新的"ServiceX"接口更改"IServices"（以及该接口的所有实现）。
public interface IServices
{
IServiceA ServiceA { get; }
IServiceB ServiceB { get; }
IServiceC ServiceC { get; }
}
现在我没什么想法了。有其他选择吗？！在这两种方法之间，我认为应该使用依赖关系的显式版本，但我很想知道是否有一种设计模式更适合这种情况。
编辑
抱歉没有说清楚。第二种方法也是构造函数注入，就像第一种方法一样。不同的是，我不会将IoC容器传递给IServiceA实现的构造函数，而是传递"IServices"，这是一个明确定义"IServicesA"依赖关系的接口。
我认为使用继承注入依赖项是解决问题的一种不灵活的方法。此外，这也不是一种方便的方式：您需要为每个需要这些依赖关系的服务提供IServices的实现，并在每次更改合同时更改它们。此外，很难用通过继承注入的依赖项来测试类——没有简单的方法可以注入模拟对象而不是真正的依赖项（除非使用setter，这本身就不是最佳实践）。
你是对的，如果你有其他选择，使用服务定位器也不是最好的方法。
我认为我们最好的方法是通过构造函数提供依赖关系。因此，您可以控制提供哪些依赖项（无论您是否使用某些IoC容器，您都可以手动提供依赖项或使用IoC容器的功能），并且您将获得可测试的解耦设计。
我知道你说的是同一级别的依赖关系。因此，这里唯一需要注意的是组件之间的循环依赖。我认为您几乎每次都可以通过构造函数遵循依赖关系，并且不会有任何问题，可能您只需要正确地重构/拆分组件。
如果我在某种程度上误解了你的问题，我很抱歉。