IOC 容器 - WCF 服务 - 我是否应该通过构造函数实例化所有依赖项

Question

我有一个 WCF 服务，它有几个不同的职责，但它为与我的代码交互的任何人提供了一个入口点。为了简单起见，假设有 2 种方法

    private IMethodAHelper _methodA;
    private IMethodBHelper _methodB;
    public MyService(IMethodAHelper methodA, IMethodBHelper methodB)
    {
      _methodA = methodA;
      _methodB = methodB;
    }
    public void MethodA() {
       _methodA.CallThis();
    }
    public void MethodB() {
       _methodB.CallThis();
    }

由于使用者只会出于一个原因调用服务，即 MethodA 或 MethodB，因此 IOC 容器将不必要地启动所有依赖项是否是一个问题？我想提供一个入口点，所以我不想拆分服务，但是当服务的每个使用者只需要一个子集时，启动所有依赖项似乎有点浪费。

我想这样做的另一种方式是这样的

    public void MethodA() {
       var methodA = ObjectFactory.GetInstance<IMethodAHelper>();
       methodA.CallThis();
    }

这允许每个"路径"提出它所需的依赖项，但是，这使得编写单元测试变得更加困难。有人有什么建议吗？启动所有依赖项的问题有多大？在服务的第一个入口点之后，通过构造函数注入依赖项是有意义的，但是在第一个入口点，推荐的方法是什么？

Answer 1

你应该坚持使用构造函数注入，而不必担心构造开销。这很少是一个问题，如果是，有一些优雅的方法来处理它。

Answer 2

作为 Mark sais，您不必担心创建不使用的依赖项，除非您有一些实际的 prof（来自探查器的时间），它们创建起来很昂贵。如果创建组件的成本很高，则可能需要使用支持延迟注入的容器，例如 AutoFac。这样，您就可以注入懒惰，该Lazy仅在首次使用时构建。

Answer 3

依赖注入的一般经验法则是，类正常工作所需的所有（必需）依赖关系都应通过构造函数注入注入。

所有（可选）依赖项都应通过属性注入注入。在这种情况下，可选是当类提供接口的默认实现，并且您希望在运行或配置时更改接口实现时。

无论如何，我同意马克·西曼的回答。

Answer 4

我不知道你在做什么的细节，但将它们分解为单独的服务可能更有意义。