Контейнер 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

Вы должны придерживаться Constructor Injection и не беспокоиться о накладных расходах на строительство. Это очень редко проблема, и если это так, есть элегантные способы справиться с ней .

Answer 2

Общее практическое правило для внедрения зависимостей заключается в том, что все (необходимые) зависимости, необходимые классу для правильной работы, должны вводиться посредством внедрения конструктора.

Все (необязательные) зависимости должны быть внедрены посредством внедрения свойства. Необязательно в этом случае, когда класс предоставляет реализацию интерфейса по умолчанию, и вы хотите изменить реализацию интерфейса во время выполнения или конфигурации.

В любом случае, я согласен с ответом Марка Симанна.

Answer 3

Как говорит Марк, вам не следует беспокоиться о создании зависимостей, которые не используются, если у вас нет фактических профессий (время от профилировщика), которые они дорогие для создания. Если у вас есть дорогие средства для создания компонентов, вы можете использовать контейнер, поддерживающий отложенное внедрение, например AutoFac . Таким образом, вы можете ввести Lazy, который будет создан только при первом использовании.

Answer 4

Я не знаю деталей того, что вы делаете, но, возможно, имеет смысл разделить их на отдельные службы.