Для начала, я не считаю использование контейнера в качестве локатора службы на фабриках анти-паттерном. Есть подлинные обстоятельства, когда это совершенно уместно. Подумайте об этом, фабрики, осведомленные о контейнерах, действительно являются расширениями контейнеров, а те, кажется, исключены из сбоев поиска сервисов. Даже самые чистые платформы IoC, такие как AutoFac или Ninject, имеют широкие возможности расширения. Наиболее типичный вариант использования этого шаблона - разрешение различных реализаций в зависимости от того, где используется сервис.
Что касается использования new
для создания экземпляров внутри фабрик, это также приемлемо. Сообщение IoC / DI там немного искажено, и , никогда не использующий new
, на самом деле является побочным эффектом, а не целью DI. Первым императивом внедрения зависимостей является создание зависимости от компонента. Завод удовлетворяет этот императив до тех пор, пока он сам вводится в компонент. При оценке таких сценариев вам необходимо задать себе следующие вопросы:
- Создает ли сам компонент свои зависимости? A: Нет, завод делает.
- Можете ли вы заставить компонент работать с разными зависимостями, не изменяя его? A: Да, путем введения другой фабрики.
Я говорил это раньше, контейнеры IoC - это просто фабрики по производству стероидов. Для 80% вариантов использования они работают из коробки. Остальные 20% могут потребовать настройки двух вышеупомянутых разновидностей. Я склонен использовать фабрики с поддержкой контейнеров, когда я хочу создавать компоненты, которые требуют как зарегистрированных зависимостей, так и некоторого ввода на фабриках времени выполнения и new
-ing, когда я создаю объекты Domain, которые не имеют зависимостей от других служб, но принимают все их строительные параметры во время выполнения.