Почему платформу Spring называют “ненавязчивой”?

лет назад был этот зверь EJB, который был очень "навязчивым". Spring рекламировался как гораздо более простой набор вспомогательных классов, и он больше походил на библиотеки, чем на фреймворки.

сегодня Весна становится новым зверем. Как бизнес с миллиардным оборотом, в их интересах блокировать людей. Да, конечно, у вас нет проблемы с зависимостью, и вы можете выйти из Spring в любой момент.

С EJB, по крайней мере, у вас есть выбор из нескольких поставщиков.

Вполне возможно использовать Spring без каких-либо прямых зависимостей от spring framework в коде вашего приложения. Это не означает, что код будет продолжать функционировать без spring, поскольку функциональность, предоставляемая spring, должна быть заменена другим IoC-контейнером или кодом, который непосредственно инстанцирует все объекты в цепочке зависимостей, но это означает, что вы можете выбрать, как соединить все с spring, или через какой-либо другой механизм.

Однако, чтобы быть действительно ненавязчивым с spring, вам нужно держать всю вашу конфигурацию вне вашего кода, что означает использование XML для всего. Это прекрасно работает в spring, но это боль в шее для разработчиков и, после появления широкого использования аннотаций в Java 5, это не совсем путь java. Поэтому Spring предоставляет множество аннотаций для соединения вещей вместе непосредственно в вашем коде. Это, очевидно, может создавать зависимости от Spring в коде, хотя все теги Spring разрешаются во время компиляции, поэтому вы можете выполнять свои классы вне контекста Spring без каких-либо зависимостей от spring jars и тому подобного. Кроме того, везде, где это возможно, пользовательские аннотации Spring были заменены общими аннотациями JEE. В Spring 3 действительно очень просто использовать только аннотации JEE плюс ограниченное количество XML для инициализации контекста приложения.

Прелесть Spring в том, что базовая функциональность, которая реализует функцию, часто может быть выбрана во время выполнения. Если вы используете ORM-систему в неуправляемом контейнере для разработки, используя родной менеджер сессий, вы можете легко переключиться на управляемые контейнером сессии в production без изменения какого-либо кода, если вы настроили приложение так, чтобы spring управлял управлением транзакциями. Методы, помеченные как @Transactional, будут подхватывать сессию и транзакцию автоматически, независимо от источника, без каких-либо изменений в коде. На самом деле, вы можете тривиально перейти на совершенно другой ORM-фреймворк, если вам так хочется, хотя это довольно редкий случай использования, по правде говоря, поэтому большинство приложений будут иметь код, специфичный для ORM-фреймворка, и/или запросы в коде доступа к данным.

Разница между Spring и старомодным "навязчивым" фреймворком заключается в том, что навязчивые фреймворки часто требуют от вас реализации определенных интерфейсов или, что еще хуже, заставляют вас наследоваться от определенных базовых классов, чтобы получить доступ к функциональности фреймворка. В последнем случае у вас не только возникает зависимость от используемого фреймворка, но и сильно ограничивается иерархическая структура классов - в языке, который допускает только однократное наследование. Последние версии EJB научились изяществу менее навязчивой модели Spring (и других), а сам EJB с тех пор стал гораздо менее навязчивым (Все дело в POJO).

Я не вижу никакой поддержки аргументу irreputable о том, что Spring теперь - это миллиардный зверь, который блокирует пользователей. Spring, если уж на то пошло, менее навязчив, чем когда-либо, предлагая при этом все большую функциональность. Конечно, можно запереть себя в Spring, и многие разработчики охотно идут на это именно потому, что накладные расходы во время выполнения при использовании Spring настолько ничтожно малы, что большинство из нас не может представить себе множество сценариев, в которых мы могли бы удалить Spring из проекта. Если мне нужна полностью управляемая среда JEE, я могу настроить ее (и запускать в контейнере любого доступного производителя). Если я хочу работать в tomcat или jetty со 100% конфигурацией и управлением временем выполнения от spring, я тоже могу это сделать. Поэтому я, как правило, совершенно счастлив использовать специфическую для Spring функциональность с риском блокировки, если это не запрещено требованиями проекта. Spring добавляет очень мало накладных расходов во время выполнения, поэтому это выбор с низким риском".

Когда дело доходит до драки, я нахожу Spring гораздо более легким в освоении, чем EJB. Я могу выполнить те же задачи с помощью любой методологии, но мне легче привлечь неопытных разработчиков, если я использую Spring по сравнению с EJB, поэтому нанимать сотрудников проще, долгосрочные затраты на обслуживание ниже, а циклы выпуска короче.

Основная привлекательность ненавязчивой структуры заключается в том, что она не мешает вам при проектировании и моделировании. Он не мешает, пока он вам не понадобится.