Если зависимость используется только в одном методе, я должен внедрить ее или использовать расположение службы?

Question

Я немного новичок в внедрении зависимостей и натолкнулся на заданный вопрос во время работы.

Допустим, у меня есть класс «Сотрудник», у которого есть один метод, этот метод, скажем, «Продвигать», тоже условно вызывается в редких сценариях.

В методе «Promote» используется объект «ValueAddition», в настоящее время рекомендуется внедрить это возражение через конструктор и глобальный объект пользователя, или я должен разрешить зависимость в самом методе?

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

Answer 1

В общем, вы всегда должны стремиться вводить зависимости, а не использовать расположение службы (т. Е. Разрешать зависимость напрямую из инверсии контейнера управления). Здесь есть отличная, довольно известная статья в блоге под названием «Сервисный локатор - это анти-шаблон», который может помочь выяснить причины.

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

• Мне нужен объект только в одном методе. Подумайте о переносе функциональности метода в другой объект. Например, возможно, метод Promote() должен быть в IEmployeePromoter, где вы решаете это, и он принимает специальный объект. Тогда вы бы позвонили Promote(Employee) и передали бы сотрудника, а не изменили зависимости для Employee. Иногда ваша инверсия управляющего контейнера будет иметь способ генерировать фабрику (например, Func<T> или Lazy<T>), чтобы помочь вам отложить разрешение до тех пор, пока оно вам действительно не понадобится.
• У меня слишком много зависимостей. Обычно это означает, что ваш объект делает слишком много. принцип единоличной ответственности может помочь вам реорганизовать ваши объекты, чтобы получить более управляемый размер. Меньшие объекты обычно нуждаются в меньшем количестве зависимостей, потому что у них гораздо меньше проблем для управления.

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