Каковы плюсы и минусы использования контейнера IOC? - PullRequest
11 голосов
/ 05 февраля 2009

Использование контейнера IOC снизит скорость вашего приложения, потому что большинство из них использует отражение под капотом. Они также могут сделать ваш код более сложным для понимания (?). На светлой стороне; они помогают создавать более слабосвязанные приложения и упрощают модульное тестирование. Есть ли другие плюсы и минусы для использования / не использования контейнера IOC?

Ответы [ 7 ]

19 голосов
/ 05 февраля 2009

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

Что касается того, чтобы сделать код более сложным для понимания - совсем наоборот! С явным указанием зависимостей намного проще понять каждый компонент, а файл (-ы) конфигурации проясняют, как все приложение соединяется вместе.

7 голосов
/ 05 февраля 2009

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

Однако, если вы работаете где-то, где большинство классов / методов очень велики и концепция рефакторинга еще не закрепилась, то попытка использовать IOC, скорее всего, только усложнит понимание программного обеспечения. МОК также должен привлекаться всеми, кто программирует проект, так что это может быть соображением.

Я вижу МОК как глазурь на торте; Мне нравится глазурь, но только на хорошем торте. Если начинать с торта плохо, сначала разберитесь с ним.

Что касается снижения производительности при использовании IOC, в большинстве случаев я не вижу в этом проблемы. Издержки не обязательно должны быть большими, и, учитывая скорость современных ЦП, большинство из вас во время работы в любом случае, скорее всего, получат доступ к данным. Если IOC окажется медленным для данного бита кода, я бы посмотрел на добавление некоторого кэширования возвращаемого объекта или удаление IOC просто из этого бита кода.

7 голосов
/ 05 февраля 2009

Ну, я полагаю, что у меня были проблемы с тем, что некоторые разработчики, похоже, не в состоянии понять IoC. У нас было несколько человек, которые были против этого только по той причине, что они их не понимали. (Не сказать, что это плохая причина быть против чего-то, совсем нет.)

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

4 голосов
/ 05 февраля 2009

Я полагаю, что предположение об уменьшенной скорости выполнения - это тот же аргумент, что и "C быстрее, чем C # / Java". Хотя это утверждение может быть верным для конкретных операций и / или структурно простых задач, это не тот случай, когда сложность возрастает.

Способ, которым DI-каркасы позволяют вам сосредоточиться на создании объектов и зависимостей, создает более эффективные системы при увеличении размера кода. Для больших приложений я почти уверен, что код на основе DI-инфраструктуры превзойдет любое альтернативное решение. В среде выполнения просто так мало избыточности, что трудно сделать ее более эффективной! Большая часть дополнительных служебных данных также возникает при первой загрузке.

Расширенные DI-контейнеры также позволяют вам создавать магию "объема", о которой вы можете только мечтать без контейнера. Используя объем-прокси, spring может выполнять следующие действия:

 A Singleton
 |
 B Singleton
 |
 C Prototype (per-invocation)
 |
 D Singleton
 |
 E Session scope (web app)
 |
 F Singleton

Эффективно, вы можете иметь десять слоев одноэлементных объектов, и внезапно появляется что-то в рамках сеанса.

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

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

Так что я думаю, что структуры DI могут изменить способ создания программ с гораздо более серьезными последствиями, чем просто DI. Это не просто прославленный способ назвать новый .

3 голосов
/ 05 февраля 2009

Я согласен со всеми ответами до сих пор.

Что я хотел бы добавить, так это то, что он создает некоторые накладные расходы, поэтому он не очень подходит для небольших приложений.

Средние и большие приложения получают наибольшую выгоду от использования IoC.

Вы также можете проверить этот вопрос для получения дополнительной информации о плюсах и минусах: Замок Виндзор Есть ли минусы?

2 голосов
/ 05 февраля 2009

В большинстве случаев вы даже не заметите снижения производительности, поскольку для «одноэлементных» объектов вся инициализация выполняется только один раз. Я также утверждаю, что IoC отличает понимание кода: наоборот, разработка в стиле IoC вынуждает вас создавать небольшие согласованные классы, которые в свою очередь легче воспринимать.

1 голос
/ 05 февраля 2009

Если вы пишете бизнес-приложение, использование контейнера управления инверсией и внедрения зависимостей (в сочетании с другими гибкими методами и инструментами) поможет вам с точки зрения производительности и надежности.

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

...