Почему Spring Framework называется «неинтрузивным»?

Question

Пружинный каркас НЕ ИНТРУЗИВ.

Не могли бы вы рассказать об этом?

Спасибо :)

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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