Как справиться с изменениями конструктора при инъекции зависимостей

Question

Я использую инфраструктуру инъекции зависимости netnet в приложении.

Этот проект использует некоторые «сторонних библиотек» (библиотеки закодированы другими командами в той же компании)

зарегистрировать некоторые классы «машина» из моей библиотеки третьей стороны, таким образом:

unityContainer.RegisterType<ICar,Car>(); 

сейчас , люди, которые разрабатывают класс «Автомобиль», решают, что было бы лучше, если бы конструктор взял логическое значение внутри конструктора.

Когда я получаю новую версию своей библиотеки, мой код разбивается во время выполнения (я не могу обнаружить ошибку в трубопроводе сборки):

Разрешающая параметр \ «hasRadio \» из конструктора автомобилей Разрешающая System.Boolean (нет) \ г \ п», "ExceptionType": "Microsoft.Practices.Unity.ResolutionFailedException" ...

Так что мой вопрос не будет, как бы вам удалось избежать подобных проблем

является ли это вопрос передовой практики для введения правил, таких как «никогда не использовать примитивы в конструкторах»?

Это мое тестовое покрытие, которое недостаточно хорошо? Например, следует ли проверять, что все классы моего графа зависимости единства создаются с помощью InjectionConstructor, когда конструктор классов содержит некоторый примитив? (Я даже не уверен, что это можно сделать с UnityContainer, чье поле регистрации не возвращает InjectionConstructors)

Должен ли я всегда создавать классы из сторонних библиотек явно (с помощью InjectionFactory), чтобы убедиться, другая команда меняет конструкторы без изменения моего кода? (Я не очень доволен этой опцией, так как она нарушает принцип введения зависимостей: /)

Answer 1

Это вопрос лучших практик по внедрению правил, таких как «никогда не использовать примитивы в конструкторах»?

Номер Primitive dependencies может использоваться как любая другая зависимость. Многие классы нуждаются в таких зависимостях для работы. Например, классу, который взаимодействует с SMTP-сервером, нужен адрес сервера и порт.

Это мое тестовое покрытие, которое недостаточно хорошо?

Вы можете добавить больше тестов, чтобы убедиться, что граф объектов действительно может быть создан, я не уверен, насколько это было бы легко. Однако, если вы используете Pure DI, вы можете обнаружить такие проблемы во время компиляции.

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

Я не думаю, что здесь есть правило. Вы можете сделать это, если хотите. Но если вы используете Pure DI, как я упоминал выше, ваша проблема уже решена.

Я не очень доволен этим вариантом, так как kind'of нарушает принцип инжекции зависимости

Я не думаю, что это нарушает принцип инверсии зависимостей. Тем не менее, я считаю, что вы нарушаете DIP по-другому:

Если вы применили принцип инверсии зависимостей правильно, то вы не должны использовать абстракцию ICar из ваших классов приложений, так как она принадлежит к стороннему компоненту, а не к вам заявление.

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

namespace MyApplication 
{ 
    public interface IMyCar 
    { 
     void DoSomething(); 
    } 
} 

namespace Adaptors 
{ 
    public class CarAdaptor : MyApplication.IMyCar 
    { 
     private readonly ThirdParty.ICar car; 

     public CarAdaptor(ThirdParty.ICar car) {this.car = car;} 

     public void DoSomething() { car.Do3rdPartyThing();} 
    } 
} 

Другая вещь, чтобы отметить здесь, что от имени класса Car, это может быть newable, не инъекционный. Вы хотите вводить только инъекционные препараты. См. this article для получения более подробной информации.