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

Question

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

Некоторые вопросы, на которые я хотел бы обратить внимание:

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

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

Мне особенно интересен опыт работы с DI-фреймворками на Python и PHP, где я думаю, что выбор не очень прост. Однако вопрос не зависит от языка.

Answer 1

Ну, говоря о Java, это звучит довольно просто ... Есть Spring с его DI, и если вы разрабатываете с использованием стека технологии Spring , то вы просто используете его DI :) Если вы используете другую технологию стек, то Spring не так просто интегрировать, и на самом деле вам это нужно? Существует Google Guice :) По сравнению с Spring, Guice - это все о DI, и в этом случае вам не нужно добавлять дополнительные библиотеки в путь к классам, возможно, некоторую дополнительную конфигурацию и т. Д. И Spring, и Guice реализовать тот же JSR 330 (Dependency Injection для Java) ... Ну, я думаю, довольно легко решить, что использовать, Spring или Guice.

С другой стороны, Java EE 6 поставляется с новым JSR 299 (контексты и внедрение зависимостей для Java; CDI ), основанным на JSR 330. Если вы собираетесь использовать сервер приложений, совместимый с Java EE 6, тогда стоит взглянуть на CDI, тогда вам не понадобятся дополнительные библиотеки, потому что сервер приложений уже понимает DI и заботится об этом. CDI позволяет вам зарабатывать больше, поскольку он размещен поверх JSR 330 и улучшает его.

Если вы по-прежнему не используете Spring / Guice, тогда лучше начать с CDI

UPDATE: Забыл упомянуть: CDI теперь реализован проектом Weld (seamframework.org/Weld), он поддерживает популярные серверы, так что вы можете попробовать его прямо сейчас. JBoss AS 6 поставляется с ним.

Сравнение между Spring и Guice, а также советы, какие из них использовать: здесь и здесь

Answer 2

Я обычно выбираю фреймворки, будь то DI или иным образом, используя следующие критерии:

1. Выберите фреймворк, который обладает необходимой функциональностью для текущей работы
2. Предпочитаю фреймворки, которыепросто - чем меньше «лишних» вещей не требуется для 1., тем лучше.
3. Предпочитают интегрированные фреймворки для языка / фреймворка, который вы уже используете.
4. Предпочитаете фреймворки,Я уже знаю и использовал

Обычно, работая над вышесказанным, это довольно очевидно.Например, последний DI-фреймворк, который я выбрал, был MEF, главным образом потому, что это был проект на C # (пункт 3), он прост, и он сделал то, что мне было нужно.