Когда уместно брать прямую зависимость от самого контейнера IoC?

Question

Я как раз собираюсь создать WorkQueueService, который может обрабатывать различные типы WorkItems. Для каждого типа WorkItem у меня будет реализация IWorkItemProcessor. Я использую IoC, поэтому все реализации IWorkItemProcessor будут зарегистрированы в контейнере. Мой WorkQueueService должен будет получить соответствующий Процессор для каждого WorkItem.

Вопрос в том, должен ли мой WorkQueueService зависеть напрямую от контейнера? Или я должен абстрагировать эту ответственность в WorkItemProcessorFactory, который будет просто тонкой оболочкой вокруг контейнера IoC?

Что другие люди сделали в этой ситуации и почему?

Answer 1

Рекомендуется абстрагировать контейнеры, создав фабрики.Только фабрики должны знать о контейнерах.У него есть два преимущества:

1. Контейнер МОК, поскольку он хорошо отобран фабриками;в будущем он может быть заменен лучшим контейнером.

2. Знание / сложность взаимодействия с контейнером IOC заключены в четко определенную фабрику.Все члены команды не должны знать о функционировании конкретного контейнера IOC.

Answer 2

Контейнер IoC - это фабрика. Я не вижу смысла оборачивать это, если только вы не думаете, что собираетесь менять и внедрять разные реализации.

Абстракции прекрасны, но в какой-то момент все слои должны закончиться, и вам нужно написать конкретную реализацию. Я не вижу смысла в упаковке контейнера IoC.

Почему зависимость должна быть явной? Если WorkQueueService имеет коллекцию IWorkItemProcessor, число которой настраивается в вашем IoC, почему бы просто не внедрить коллекцию, как любую другую зависимость? Я не понимаю, почему WorkQueueService нужна ссылка на контейнер IoC.