Правильно ли иметь 2 конструктора, один для внедрения зависимостей, а другой - для разрешения инъекций?

Question

В моем классе есть 2 конструктора:

public class VuelingCacheWebServices : IVuelingCacheWebService
    {
        public IVuelingCache apiConnector { get; set; }

        public VuelingCacheWebServices(IVuelingCache ApiConnector)
        {
            apiConnector = ApiConnector;
        }

        public VuelingCacheWebServices()
            : this(new VuelingCache())
        { }
    }

Как вы можете видеть, у меня есть один конструктор в зависимости от IVuelingCache и конструктор по умолчанию, который создает экземпляр для передачи первому конструктору.Это правильно?таким образом я избавляюсь от класса Factory.

Answer 1

Это один из способов убедиться, что у вас есть действительный экземпляр IVuelingCache - у этого шаблона есть имя - инъекция зависимости бедняка.

Некоторые см. это как анти-шаблон, так как вы жестко программируете реализацию «по умолчанию» в своем коде.

Answer 2

Есть несколько проблем с вашим подходом:

1. Это делает ваш код менее понятным. Мало того, что написано больше кода, но и сложнее увидеть, какие зависимости принимает класс. Когда у вас есть один единственный конструктор, сразу становится ясно, каковы его зависимости.
2. Это делает класс зависимым от конкретных экземпляров. Это затрудняет разделение абстракции и реализации и может быть плохим с архитектурной точки зрения.
3. Это заставляет вас вносить изменения в этот класс при изменении реализаций, что плохо для удобства сопровождения. Скажем, например, что ваше приложение использует ICommandHandler<T> интерфейсы в качестве абстракции для выполнения бизнес-команд, и что ваш класс зависит от ICommandHandler<UpdateUserCommand> и указывает на конкретный UpdateUserCommandHandler. Когда вы позже захотите обернуть любой ICommandHandler<T> в DurationLoggingCommandHandler<T>, DeadLockRetryCommandHandler` или что-то еще, вам нужно пройти через ваше полное приложение, чтобы заменить все зависимости, в противном случае это просто вопрос перемонтирования конфигурации при запуске путь вашего приложения.

Answer 3

Нет, это не очень хорошая идея, потому что ваш класс станет знанием о реализации IVuelingCache (new VuelingCache()).

Answer 4

Существует некоторая дискуссия о том, что эта модель является хорошей идеей:

http://lostechies.com/chadmyers/2009/07/14/just-say-no-to-poor-man-s-dependency-injection/

По моему мнению, если у вас есть хорошее значение по умолчанию , которое не 't логически внешняя зависимость, тогда вы должны указать это значение по умолчанию.Если ваше «значение по умолчанию» действительно не должно быть значением по умолчанию, или вы хотите соединить части, которые находятся слишком далеко друг от друга, то не используйте этот шаблон.

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

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