Контейнеры DI / IoC и фабрики: где я могу настроить приложение и почему?

Я пытаюсь выяснить, когда использовать реестр DIC / IoC для настройки моего программного обеспечения и когда использовать фабрики, а также обосновать любой из этих подходов.

Я использую StructureMap в качестве моего DI-контейнера (DIC), который легко настроить с помощью реестров. В DIC практически все зарегистрированные объекты являются статическими в том смысле, что мне не нужно изменять / обменивать какую-либо реализацию / экземпляр во время выполнения, после того, как DIC настроен, и они настроены в DIC как одиночные пакеты. Однако, поскольку мое программное обеспечение (ПО) будет работать на разных устройствах, мне нужно выбрать реестр для конкретного устройства в зависимости от устройства, на котором работает мое ПО, чтобы соответствующим образом настроить оборудование.

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

Теперь скажите, что у меня есть тип плагина IMotorс конкретными типами Motor1и Motor2который должен обрабатываться на заводе. Теперь есть два способа решить, как настроить мое устройство:

1. Я передаю информацию об устройстве , что SW работает на к MotorFactoryи возвращает соответствующий двигатель, либо Motor1или Motor2. В этом случае логика принятия решения находится внутри Фабрики.
2. Я настраиваю DIC в соответствии с устройством, на котором он работает, и создаю две фабрики Motor1Factoryи Motor2Factory, где одна создает, Motor1а другая Motor2. В этом случае я бы отличаясь записи реестра для IMotorв устройства специальных реестрах , которые используют либо Motor1Factoryили Motor2Factory.

Теперь мой вопрос: какой из этих двух методов предпочтительнее и почему? Мне кажется, что первый случай не является прямым и запутанным, так как я распространяю логику, которая решает, какой тип создавать в базе кода. Тогда как во втором случае я эффективно умножаю количество фабрик в моем коде, так как мне понадобится фабрика для (почти) каждого конкретного типа. Это становится еще более запутанным для меня, когда к смеси добавляются абстрактные фабрики.

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

Если вы используете оба, я пойду на что-то простое:

• DI / IoC: для каждой конфигурации, которая не изменяется во время выполнения.
• Factory: для создания экземпляра объектов во время выполнения, который зависит от входных параметров времени выполнения. Экземпляры фабрики вводятся контейнером DI.

Абстрактные фабрики используются, когда у вас есть объекты, связанные через иерархию, которая должна меняться вместе. Я не вижу этого здесь.

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

Трудно выбрать именно потому, что фабрика и DIC делают очень похожие вещи. Разница в том, что фабрика ориентирована на конкретную проблему, а DIC носит более общий характер.

Все сводится к этому вопросу: нужен ли вам код, специфичный для этой проблемы, который будет жить на фабрике? Или это более общее, как чтение деталей конфигурации из файла?

Имейте в виду , что в то время как вы можете выбирать только между Motor1и Motor2сегодня, завтра может быть Motor3. Подарите дизайн, который Motor3легко добавить.

Я бы отделил логику «какой двигатель использовать» в специальную фабрику, называемую « Построитель» (шаблон), и использовал бы IOC-контейнер для обоих двигателей в качестве детали реализации компоновщика.

Как общее правило:

• вам нужна фабрика (или компоновщик), если вам нужно создать много динамических объектов класса / интерфейса. (т.е. для каждого автомобиля, который вы производите, вы должны создать один новый мотор)
• если вам нужен только один статический экземпляр класса, ioc / di может выполнить эту работу за вас (т. е. вам нужен только один статический экземпляр paymentservice и один статический экземпляр MotorBuilderService)