Вполне возможно использовать Spring без каких-либо прямых зависимостей от среды Spring в вашем коде приложения. Это не означает, что код будет продолжать функционировать без Spring, поскольку функциональность, предоставляемую Spring, необходимо будет заменить другим контейнером IoC или кодом, который непосредственно создает экземпляры всех объектов в цепочке зависимостей, но это означает, что вы можете выбрать связать вещи с пружиной или с помощью другого механизма.
Однако, чтобы быть по-настоящему ненавязчивым с помощью Spring, вам нужно хранить всю свою конфигурацию вне кода, что означает использование XML для всего. Весной это работает прекрасно, но это боль в шею для разработчиков, и, так как с появлением повсеместного использования аннотаций в Java 5, это не совсем Java-способ. Поэтому Spring предоставляет множество аннотаций для соединения вещей прямо в вашем коде. Очевидно, что это может создать зависимости от Spring внутри кода, хотя все теги Spring разрешаются во время компиляции, поэтому вы все равно можете выполнять свои классы вне контекста Spring без каких-либо зависимостей от Spring JAR и тому подобного. Кроме того, там, где это возможно, пользовательские аннотации пружин были заменены общими аннотациями JEE. В Spring 3 действительно довольно просто использовать только аннотации JEE плюс ограниченное количество XML для инициализации контекста приложения.
Прелесть весеннего способа работы в том, что базовая функциональность, которая реализует функцию, часто может быть выбрана во время выполнения. Если вы используете систему ORM в неуправляемом контейнере для разработки, используя собственный менеджер сеансов, вы можете легко переключиться на управляемые контейнерные сеансы в производственной среде, не изменяя никакого кода, если вы настроили приложение, чтобы позволить Spring обрабатывать управление транзакциями. Методы, помеченные как @Transactional, автоматически выбирают сеанс и транзакцию, независимо от источника, без каких-либо изменений в коде. На самом деле, вы можете тривиально переключиться на совершенно другую платформу ORM, если у вас такая склонность, хотя на самом деле это довольно редкий случай использования, поэтому большинство приложений будут склонны иметь специфичный для платформы ORM код и / или запросы при доступе к данным. код.
Разница между Spring и старомодным «навязчивым» фреймворком заключается в том, что навязчивые фреймворки часто требуют от вас реализации определенных интерфейсов или, что еще хуже, вынуждают вас наследовать от определенных базовых классов, чтобы получить доступ к функциональности фреймворка. В последнем случае вы не только зависите от используемой вами структуры, но и значительно ограничивает структуру иерархии классов - в языке, допускающем только одиночное наследование. Последние версии EJB извлекли уроки из элегантности менее навязчивой модели Spring (и других), а сам EJB с тех пор стал гораздо менее навязчивым (все дело в POJO).
Я не вижу какой-либо поддержки неопровержимого аргумента о том, что весна теперь зверь на миллиард долларов, который запирает пользователей. Весна, во всяком случае, менее навязчива, чем когда-либо, предлагая еще больше функциональности. Конечно, можно привязать себя к весне, и многие разработчики совершенно готовы сделать это именно потому, что накладные расходы на использование пружины настолько малы, что большинство из нас не может представить множество сценариев, в которых мы могли бы удалить весна из проекта. Если мне нужна полностью управляемая среда JEE, я могу настроить ее (и запустить в контейнере любого доступного поставщика). Если я хочу работать в tomcat или jetty со 100% конфигурацией и управлением временем работы, приходящимся на весну, я тоже могу это сделать. Поэтому я, как правило, совершенно счастлив использовать пружинные функции с риском блокировки, если только требования проекта не запрещают этого. Spring добавляет очень мало накладных расходов во время выполнения, поэтому это выбор с низким риском.
Когда наступает время пуша, я нахожу, что Spring гораздо легче выучить, чем EJB.Я могу сделать то же самое с любой методологией, но проще привлечь разработчиков, которые неопытны, если я использую Spring по сравнению с EJB, поэтому найм проще, затраты на длительное обслуживание ниже, а циклы выпуска короче.