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

Kev*_*vin 5 c# wcf inversion-of-control

我有一个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();
    }
Run Code Online (Sandbox Code Playgroud)

因为消费者只会因为一个原因(MethodA或MethodB)调用该服务,所以IOC容器会不必要地启动所有依赖项是一个问题吗?我想提供一个入口点,所以我不想拆分服务,但是当服务的每个使用者只需要一个子集时,启动所有依赖关系似乎有点浪费.

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

    public void MethodA() {
       var methodA = ObjectFactory.GetInstance<IMethodAHelper>();
       methodA.CallThis();
    }
Run Code Online (Sandbox Code Playgroud)

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

Mar*_*ann 5

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