Использование контейнера IOC уменьшит скорость вашего приложения, поскольку большинство из них использует отражение под капотом. Они также могут сделать ваш код более трудным для понимания (?). На светлой стороне; они помогают создавать более слабосвязанные приложения и упрощают модульное тестирование. Существуют ли другие плюсы и минусы для использования/не использования контейнера МОК?Каковы преимущества и недостатки использования контейнера IOC?
В большинстве случаев вы даже не заметили бы снижение производительности, поскольку для объектов «singleton» вся инициализация выполняется только один раз. Я также хотел бы утверждать, что IoC отличается от понимания кода: напротив, разработка IoC-стиля заставляет вас создавать небольшие когерентные классы, которые, в свою очередь, легче искать.
Ну, я полагаю, что конфликт, который я испытал, заключается в том, что некоторые разработчики, похоже, не могут понять IoC. У нас было несколько человек, которые были против этого, потому что они не понимали их. (Не сказать, что это плохая причина, чтобы быть против чего-то, совсем нет.)
Это добавляет немного абстракции, которая всегда, похоже, что-то может смутить кого-то, но я бы сказал, что плюсы намного перевешивают минусы в большинстве случаев.
Если вы используете контейнер IOC простым способом, отражение используется только при запуске - приложение подключается к началу, а затем выполняется как обычно без какого-либо вмешательства из контейнера. Конечно, если вы используете IOC для разрешения зависимостей после того, как вы начали работать, это может быть несколько иначе, хотя я бы все же ожидал, что он будет лениво разрешать и кэшировать, если вы не настроили его на создание новых экземпляров каждый время.
Что касается того, чтобы сделать код более сложным для понимания - совершенно наоборот! С явно выраженными зависимостями гораздо проще понять каждый компонент, а файл конфигурации (ы) ясно показывает, как все приложение зависает вместе.
Я согласен со всеми ответами до сих пор.
Что я хотел бы добавить, это то, что он создает немного накладных расходов, поэтому он не подходит для небольших приложений.
Средние и большие приложения приносят пользу от использования IoC.
Вы также можете проверить этот вопрос для получения дополнительной информации о преимуществах и недостатках: Castle Windsor Are There Any Downsides?
Я считаю, что предположение о пониженной скорости выполнения является таким же видом аргумента, как «C быстрее, чем C#/Java». Хотя это утверждение может быть истинным для конкретных операций и/или конструктивно простых задач, это не так, когда сложность момента возрастает.
Способ DI-framework позволяет сосредоточиться на создании объекта и зависимости создает более эффективные системы при увеличении размера кода. Для больших приложений я почти уверен, что код на основе DI-framework будет превосходить любое альтернативное решение. Просто так мало избыточности во время выполнения, что трудно сделать его более эффективным! Большая часть дополнительных накладных расходов также при первой загрузке.
Продвинутые контейнеры DI также позволяют делать магию «масштаба», о которой вы можете только мечтать без контейнера. Использования СКОП-прокси, spring можно сделать следующее:
A Singleton
|
B Singleton
|
C Prototype (per-invocation)
|
D Singleton
|
E Session scope (web app)
|
F Singleton
Эффективно вы можете иметь десять слоев одноэлементных объектов и вдруг что-то сессия область действия показывает вверх.
Такие вещи, как безопасность, могут быть введены совершенно иначе, чем в противном случае. Часто возникает классический парадокс: часто слой GUI должен иметь сложные знания о разрешениях безопасности. Довольно часто уровень сервиса также необходим, но часто на другом уровне детализации (обычно менее подробный, чем gui). Классический подход состоял бы в том, чтобы отправить его как параметры, поместить его в threadlocal или запросить службу. С весной вы можете просто вставлять его туда, где вам это нужно, и никто другой не должен знать.
Это фактически изменяет разработку приложений в целом. Мне было очень трудно приспособиться к этому, но после этой боли я вижу, что это действительно намного ближе к тому, как должно быть (в отличие от того, как мы научились это делать).
Таким образом, я думаю, что каркасы DI имеют потенциал изменения способа создания программ с гораздо более значительными последствиями, чем просто DI. Это не просто прославленный способ позвонить .
Я думаю, справедливо сказать, если у вас есть экспертное понимание того, как использовать МОК и, как правило, писать хороший код в любом случае, тогда IOC сделает ваш код более понятным для всех, кроме самых маленьких.
Однако, если вы работаете где-то там, где большинство классов/методов очень велико, а концепция рефакторинга еще не взяла верх, тогда попытка использовать МОК, скорее всего, просто сделает программное обеспечение более понятным. МОК также обязана всем называть, что программы по проекту, так что это может быть предметом рассмотрения.
Я вижу МОК как глазурь на торте; Мне нравится обледенение, но только на хорошем пироге. Если пирог не с чем начать, сначала попробуйте пирог.
Что касается служебных накладных расходов на использование IOC, я не вижу в этом проблемы как проблемы. Накладные расходы не должны быть большими, и, учитывая скорость сегодняшнего процессора, большинство из вас время запуска, вероятно, будет доступ к данным в любом случае. Если IOC оказался медленным для определенного бита кода, я бы посмотрел на добавление некоторого кэширования возвращаемого объекта или удаление IOC только с этого бита кода.
Если вы пишете бизнес-приложение, использование контейнера с инверсией контроля и зависимостей (в сочетании с другими гибкими практиками и инструментами) поможет вам с точки зрения производительности и надежности.
Кроме того, ваше приложение, вероятно, потратит большую часть своего процессорного времени на ожидание ресурсов или ожидание взаимодействия с человеком и ничего полезного. Ваша заявка должна иметь достаточную мощность, чтобы сэкономить на несколько микросекунд отражения.
+1 за много здравого смысла в вашем ответе. –
Как только вы используете контейнер IoC, код легче понять. Однако, прежде чем они его используют, некоторым разработчикам может быть сложно понять, зачем им это нужно. Проблемы сложности, которые он решает, обычно не присутствуют в игрушечных приложениях. – Anthony
Я согласен и не согласен: независимые фрагменты легче понять изолированно. Но вся картина и проводка более уместны. Пример. Вы читаете исходный код службы, вызывающей метод сохранения репозитория. Я прошу у вашего редактора «goto definition of save» вы попадаете в определение интерфейса, но не в конкретную используемую реализацию. – k3b
@ k3b: Конечно, вам тоже нужно иметь вид на сантехнику ... но я не думаю, что этого достаточно, чтобы помешать ему тесно связать разные услуги друг с другом. –