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

【问题标题】：IOC Container - WCF Service - Should I instantiate all dependencies via constructor?IOC 容器 - WCF 服务 - 我应该通过构造函数实例化所有依赖项吗？
【发布时间】：2011-05-04 12:56:04
【问题描述】：

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

    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();
    }

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

【问题讨论】：

标签： c# wcf inversion-of-control

【解决方案1】：

您应该坚持使用构造函数注入，而不必担心构造开销。 It's very rarely an issue, and if it is, there are elegant ways to deal with it.

【讨论】：

【解决方案2】：

正如 Mark 所说，您不必担心创建不使用的依赖项，除非您有一些实际的 prof（来自 profiler 的时间），它们的创建成本很高。如果您有一些创建组件的成本很高，您可能希望使用支持延迟注入的容器，例如 AutoFac。这样你就可以注入 Lazy，它只会在第一次使用时构建。

【讨论】：

【解决方案3】：

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

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

无论如何，我同意 Mark Seemann 的回答。

【讨论】：

【解决方案4】：

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

【讨论】：