Является ли шаблон поставщика реализацией IOC?

Question

Является ли шаблон поставщика реализацией IOC? Если нет, то почему нет?

(чтение статьи Мартина Фаулера на IOC)

Answer 1

На мой взгляд, да, шаблон провайдера - это форма инверсии контроля.

Что я рассуждаю?

По своей сути IoC является очень общей концепцией, настолько, что Мартин Фаулер говорит о том, что чтение пользовательского ввода из командной строки представляет собой форму IoC .

В модели провайдера инверсия происходит, когда платформа провайдера решает, какой провайдер будет использоваться при вызове данного метода. Например, когда вы вызываете Membership.GetUser, ваш код делегирует контроль над тем, какого поставщика Membership использовать, структуре провайдера.

Как говорит Фаулер: «Инверсия контроля - это общая характеристика фреймворков», и если подумать, многие паттерны связаны с IoC (например, паттерн стратегии). Я бы даже сказал, что даже полифизм является формой IoC (пункт, к которому я бы с удовольствием хотел бы услышать контраргумент).

Answer 2

Я думаю, что даже если это так, вам не обязательно использовать его «вместо» МОК, иначе вы пропустите и получите грязную кодовую базу. Контейнеры IOC, как правило, могут быть сконфигурированы в коде, который может быть более мощным и гораздо более простым в обслуживании, тогда как модель поставщика должна быть настроена в Web.Config.

На самом деле я рассматриваю возможность отойти от модели провайдера, поскольку использую контейнер IOC, потому что это выглядит как перебор.

Узнайте больше на моем блоге - надеюсь, блог тоже получит хорошие отзывы об этом: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html

Answer 3

Spring использует BeanFactory и его конкретные реализации, наиболее важной из которых является ApplicationContext. Не знаю, что делает Guice .