CDI означает «внедрение контекста и зависимости», в то время как Spring представляет собой законченную экосистему вокруг контейнера ввода зависимости. Чтобы сравнить оба, вы должны дифференцировать сравнение.
Внедрение зависимостей обрабатывается обоими контейнерами. Основным отличием является тот факт, что CDI обрабатывает DI динамически (он же: с состоянием) - это означает, что зависимости разрешаются в время выполнения . Подход Spring - static - это означает, что компоненты соединяются вместе в время создания . Хотя на первый взгляд CDI-путь может показаться немного необычным, он намного лучше и предлагает гораздо больше и более продвинутых опций (я пишу это на фоне двух продуктивных приложений CDI).
Если вы посмотрите на экосистему , ситуация будет иной: Spring поставляется в комплекте с большим количеством банок (> 150), тогда как CDI сам по себе довольно мал. Типичное использование CDI было бы внутри сервера приложений Java EE 6, но вы можете легко заставить его работать в движке сервлета или даже в Java SE. Это означает, что использование CDI не предполагает использования Hibernate, JPA, EJB или чего-либо еще - это ваше дело.
Если вам нужна дополнительная функциональность, CDI поставляется с концепцией переносимых расширений (что само по себе делает API полезным). Существуют независимые модули расширения, такие как Apache CODI и Seam 3, которые охватывают такие темы, как безопасность, рассылка, отчетность и т. Д.
Подводя итог: CDI - это не «замена» для экосистемы Spring, а скорее улучшение по сравнению с механизмом внедрения зависимостей Spring. Это часть Java EE 6, поэтому, если вы работаете с GlasFish с Java EE 6, вам обязательно нужно выбрать CDI. На мой взгляд, ваш вопрос: можно ли заменить Spring на Java EE 6? Я думаю, мой ответ довольно очевиден; -)
Взгляните на Сварка , чтобы получить хорошее начало ...