Использование фабрик для создания нескольких объектов при использовании Dependency Injection - PullRequest
5 голосов
/ 08 июня 2011

Я пытаюсь понять, как создать несколько объектов при использовании Dependency Injection. Насколько я понимаю, стандартный подход заключается во внедрении Фабрики, которая затем используется для создания объектов. Часть, с которой я борюсь, это то, как Фабрика создает объекты. Пока я вижу два возможных решения:

Фабрика просто использует new () для создания объекта.

  • Разве я не должен освобождать меня от использования новых для не значимых объектов?
  • Что произойдет, если создаваемый объект имеет зависимости, которые могут быть разрешены IoC?

Использование контейнера в качестве сервоклокатора

  • решает проблемы только новых объектов за счет введения антипаттерна или он больше не является антипаттерном, если использование сервикокатора ограничено на фабриках?

Такое чувство, что я могу выбрать между плохим и плохим решением. Я что-то упускаю или понимаю, что-то здесь не так?

Редактировать В настоящее время я вообще не использую Ioc, но думаю о Ninject. Хотя Autofac DelegateFactories звучит очень многообещающе.

Ответы [ 2 ]

3 голосов
/ 10 июня 2011

Для начала, я не считаю использование контейнера в качестве локатора службы на фабриках анти-паттерном. Есть подлинные обстоятельства, когда это совершенно уместно. Подумайте об этом, фабрики, осведомленные о контейнерах, действительно являются расширениями контейнеров, а те, кажется, исключены из сбоев поиска сервисов. Даже самые чистые платформы IoC, такие как AutoFac или Ninject, имеют широкие возможности расширения. Наиболее типичный вариант использования этого шаблона - разрешение различных реализаций в зависимости от того, где используется сервис.

Что касается использования new для создания экземпляров внутри фабрик, это также приемлемо. Сообщение IoC / DI там немного искажено, и , никогда не использующий new, на самом деле является побочным эффектом, а не целью DI. Первым императивом внедрения зависимостей является создание зависимости от компонента. Завод удовлетворяет этот императив до тех пор, пока он сам вводится в компонент. При оценке таких сценариев вам необходимо задать себе следующие вопросы:

  1. Создает ли сам компонент свои зависимости? A: Нет, завод делает.
  2. Можете ли вы заставить компонент работать с разными зависимостями, не изменяя его? A: Да, путем введения другой фабрики.

Я говорил это раньше, контейнеры IoC - это просто фабрики по производству стероидов. Для 80% вариантов использования они работают из коробки. Остальные 20% могут потребовать настройки двух вышеупомянутых разновидностей. Я склонен использовать фабрики с поддержкой контейнеров, когда я хочу создавать компоненты, которые требуют как зарегистрированных зависимостей, так и некоторого ввода на фабриках времени выполнения и new -ing, когда я создаю объекты Domain, которые не имеют зависимостей от других служб, но принимают все их строительные параметры во время выполнения.

2 голосов
/ 08 июня 2011

Хотя интерфейс для вашей фабрики будет определяться на уровне приложения, вы обычно определяете реализацию этого класса фабрики близко к вашей конфигурации DI, таким образом, как часть вашего составного корня .Хотя вызов контейнера непосредственно из вашего кода является реализацией антишаблона Service Locator , любой код, определенный внутри корня композиции, является просто mechanics и поэтому не является Service Locator.Пока обновление объектов или вызов в контейнер выполняется внутри (или очень близко) к корню композиции, это не является проблемой, поскольку приложение все равно будет очищено от любого локатора / контейнера.

ВДругими словами: используйте фабричный подход.Нужно ли вам new поднять объекты непосредственно внутри вашей фабрики или использовать контейнер, зависит от объектов.Позволять контейнеру создавать объекты предпочтительнее, особенно когда они получают зависимости самостоятельно, но не все объекты могут быть созданы контейнером.В этом случае вам нужно вернуться к операции new.И то и другое хорошо, когда код является частью корня композиции, а не приложения.Сам завод может иметь свои собственные зависимости.Это не должно быть проблемой.Вы можете разрешить контейнеру подключить экземпляр фабрики.

...