Вот такой странные вопрос
Зачем нужен спринг с его xml-конфигурационным файлом и неужели ради IoC люди возятся с ним?

Ну во-первых, кроме XML-конфигурации Spring допускает настройку с помощью аннотаций, что некоторые считают более удобным подходом.

А вообще, Spring - это больше чем просто IoC контейнер, хоть тот и является его ключевой частью. Spring - большой фреймворк со своей областью применения. В своё время на проекте мы отказались от него в пользу google-guice, т.к. нужен был только IoC.

integral,  Spring Roo - convention over configuration и никакого XML  

это все хорошо, но не отвечает на вопрос: зачем мне нужен Spring в моем приложении?

Хе 

А никто не гарантирует, что он обязательно нужен вам в вашем приложении. Скорее всего, раз такой вопрос встал - то таки не нужен   
А что-у вас за приложение-то?

Речь не о конкретном приложение, а скорее продолжение дискусии по-поводу использований спринга во всех приложениях подряд
А вы можете привести пример уместного использования спринга в приложении?

Спринг уместен в случае, если приложение разворачивается на томкате, например, и нужно автоматическое управление транзакциями и т.п.
Хотя я бы в таком случае воткнул в томкат openejb.

Мне кажется, наиболее уместно использовать его если есть перспектива использования в приложении АОП, транзакций на уровне объектов, если вероятна смена модели доступа к данным. Для реализации веб-интерфейса я его не использовал никогда, но наслышан о нескольких важных фичах, как то Spring Web MVC + Spring Web Flow, Spring security. Ну и другие интересные технологии типа JMX, JMI, RPC(RMI, SOAP)

Разумеется, можно выбрать любой стек технологий, это уже скорее дело вкуса и опыта работы с каждой из них. Главное, без фанатизма. В большом проекте с АОП мы использовали Spring, для чистого IoC-контейнера без излишеств - не стали.

Spring зародился как альтернатива ЕЕ - мол, слишком громоздко для большинства случаев. И не могут остановиться. Теперь это "наше все" и сами становятся монстрами.

+1 COVD

в java ee 6 уже есть IOC javax.inject.

Что теперь будет делать спринг - я не знаю...

Вроде как EJB всё это умеют.
Во всяком случае - AOP, JTS/JTA, удалённые вызовы - точно есть, сам юзал. JMX - наверное зависит от контейнера, в JBoss-е есть. 
Удалённые вызовы через различные протоколы - RMI/Socket/HTTP(S) - зависит от контейнера, в JBoss-е всё перечисленное есть. 

Как я понимаю, когда-то давно EJB были весьма тяжёлыми и требовали неслабого сервера. Вот как лёгкая альтернатива и был создан Spring.
С Java EE 5/EJB 3 и выше, а также на современном железе старые проблемы уже неактуальны.

Слабое связывание?

Если рассматривать только IoC, то:
1. Без IoC приложения выглядят убого из-за использования Фабрик и Одиночек, что делает приложения трудно тестируемым и деревянным. 
2. Spring IoC - прост как пень, для его изучения хватит неполного дня (конечно, для глубоких познаний дня не хватит, однако глубокие знания не обязаны быть, чтоб уметь пользоваться DI).
3. Для IoC не обязательно использовать Spring: есть тот же Guice, можно и самому сварганить IoC Фабрику, хотя не уверен, что это прокатит на крупных приложениях. 

Dependency Inversion Principle, Low Coupling, High Cohesion, следовательно: легкость переиспользования компонент и понимания кода.

Кстати, ИМХО, очень правильный вопрос. Сам я сопротивлялся спрингу до последнего. Пришлось использовать, так как ничего лучше Spring Security не нашел. Сейчас использую Spring Security и Spring JPA (+ JPA Generic Dao, + ZK). 
* Ничего плохого про спринг сказать не могу, кроме сожеления о 2-3 потраченных днях на написание xml конфигов. Плюс чувствуется "тяжесть" спринга на хостинге.
* Ничего хорошего про спринг пока тоже сказать не могу . Такое впечатление, что все что делается через спринг можно все делать как-то проще, через те же аннотации (пусть даже и - через спринг на нижнем уровне, как работает в Grails). 

Это сообщение отредактировал(а) Andrey1 - 28.8.2010, 09:55