Spring @Autowired

Question

Каковы плюсы и минусы использования @ Autowired в классе, который будет подключен к Spring?

Просто чтобы уточнить, я говорю конкретно о аннотации @ Autowired , а не об автопроводке в XML.

Я, вероятно, просто не понимаю этого, но для меня это выглядит почти как анти-паттерн - ваши классы начинают осознавать, что они привязаны к структуре DI, а не просто являются POJO. Может быть, я жажду наказания, но мне нравится иметь внешний XML-конфиг для bean-компонентов, и мне нравится иметь явные связи, так что я точно знаю, что и где подключено.

Answer 1

Долгое время я считал, что имеет смысл иметь «централизованную, декларативную конфигурацию», такую ​​как XML-файлы, которые мы все использовали. Затем я понял, что большинство файлов в файлах не было конфигурацией - оно никогда не менялось нигде после разработки, никогда. Затем я понял, что «централизованный» имеет значение только в довольно небольших системах - только в небольших системах вы когда-нибудь сможете получить файл конфигурации в целом . И какова на самом деле ценность понимания разводки в целом, когда одни и те же «разводки» в основном дублируются зависимостями в коде? Поэтому единственное, что я сохранил, - это метаданные (аннотации), которые все еще являются декларативными. Эти никогда не изменяются во время выполнения, и они никогда"данные конфигурации", которые кто-то изменит на лету - поэтому я думаю, что хранить их в коде - это хорошо.

Я использую полное автоматическое подключение столько, сколько могу. Я люблю это. Я не вернусь к весне старого образца, если не буду угрожать оружием. Мои причины для полного предпочтения @Autowired со временем изменились.

Сейчас я думаю, что наиболее важной причиной использования автопроводки является то, что в вашей системе есть одна абстракция, которую нужно отслеживать. «Имя боба» фактически исчезло. Оказывается, имя компонента существует только из-за xml. Таким образом, полный слой абстрактных косвенных указаний (где вы бы связали имя bean-компонента "foo" с "bar" bean-компонента) пропал. Теперь я подключаю интерфейс «Foo» непосредственно к своему компоненту, и реализация выбирается профилем времени выполнения. Это позволяет мне работать с кодом при отслеживании зависимостей и реализаций. Когда я вижу в своем коде автосвязанную зависимость, я могу просто нажать кнопку «перейти к реализации» в моей среде IDE, и появляется список известных реализаций. В большинстве случаев есть только одна реализация, и я прямо в классе. Не может быть намного проще, чем я, и я всегда знаю точно какая реализация используется (я утверждаю, что обратная сторона ближе к истине с проводкой xml - забавно, как меняется ваша перспектива!)

Теперь вы можете сказать, что это просто очень простой слой, но каждый уровень абстракции, который мы добавляем к нашим системам , увеличивает сложность. Я действительно не думаю, что XML когда-либо добавлял реальную ценность к любой системе, с которой я работал.

Большинство систем, с которыми я когда-либо работал, имеют только одну конфигурацию рабочей среды выполнения. Там могут быть другие конфигурации для тестирования и т. Д.

Я бы сказал, что полная автоматическая разводка - это пружина на рельсах: она охватывает представление о том, что существует нормальная и распространенная схема использования, которой придерживается большинство вариантов использования. С конфигурацией XML вы разрешаете много последовательного / противоречивого использования конфигурации, которое может / не может быть предназначено. Я видел, как много xml-конфигураций выходят за рамки несогласованностей - реорганизуются ли они вместе с кодом? Мысль нет. Есть ли эти вариации по какой-то причине? Обычно нет.

Мы почти не используем квалификаторы в нашей конфигурации и нашли другие способы решения этих ситуаций. Это явный «недостаток», с которым мы сталкиваемся: мы немного изменили способ кодирования, чтобы он стал более плавным при взаимодействии с автопроводкой: хранилище клиентов больше не реализует общий интерфейс Repository<Customer>, но мы создаем интерфейс CustomerRepository, расширяющий Repository<Customer>. Иногда также есть хитрость или два, когда дело доходит до подклассов. Но это, как правило, просто указывает нам направление более строгого набора текста, что, как я считаю, почти всегда является лучшим решением.

Но да, вы привязаны к определенному стилю DI, который в основном делает весна. Мы даже больше не публикуем сеттеры для зависимостей (так что вы можете утверждать, что мы +1 в отделе инкапсуляции / сокрытия информации) У нас все еще есть некоторый xml в нашей системе, но xml в основном only содержит аномалии. Полное автоматическое подключение прекрасно сочетается с XML.

Теперь нам нужно только, чтобы @Component, @Autowired и остальные были включены в JSR (например, JSR-250 ), поэтому нам не нужно связывать с весны. Так происходило в прошлом (на ум приходит java.util.concurrent), так что я не был бы полностью удивлен, если это повторилось.

Answer 2

Для меня вот что мне нравится / не нравится в пружине и автоматическом подключении.

Плюсы:

• Автоматическое подключение избавляет от неприятной конфигурации XML.
• Гораздо проще использовать аннотации, которые позволяют вводить напрямую, используя поля, методы установки или конструкторы. Также позволяет аннотировать и «квалифицировать» введенные бобы.

Минусы:

• Использование автоматического подключения и аннотаций делает вас зависимым от библиотек Spring, где, как и при настройке XML, вы можете выбрать запуск с Spring или без него. Как вы сказали, вы привязаны к DI-фреймворку.
• В то же время мне нравится возможность «квалифицировать» бины, для меня это делает код действительно грязным. Если вам нужно внедрить один и тот же компонент в нескольких местах, я видел повторение одного и того же имени строки. Мне кажется, это может привести к ошибкам.

Я начал использовать автоматическую проводку почти исключительно на работе, потому что мы зависим столько от Спринг интеграции все равно, что проблема зависимости является спорной. Я работал над проектом Spring MVC, в котором широко использовалась автоматическая разводка, и мне было немного трудно обернуться.

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

Answer 3

Мы переходим от @Autowire к конфигурации XML в нашем большом проекте. Проблема заключается в очень низкой производительности начальной загрузки. Сканер автопроводки загружает все классы из пути к классам автопоиска, поэтому во время инициализации Spring загружается множество классов.

Answer 4

Было очень мало дискуссий о переключении сред. Большинство проектов, над которыми я работал, было реальной проблемой для внедрения зависимостей в зависимости от среды, над которой мы работаем. С xml config это довольно просто с Spring EL, и я не знаю ни одного хорошего решения с аннотациями. Я только что понял один:

    @Value("#{${env} == "production" ? realService : dummyService}")
    private SomeService service;

Это должно работать, но не хорошее решение imho.

Answer 5

Я перешел на @Autowire. Поддержка конфигурации XML для чего-либо, кроме небольшого проекта, стала самостоятельной задачей, и понимание быстро ухудшилось.

IntelliJ обеспечивает хорошую (не идеальную) поддержку аннотаций Spring.

Answer 6

Мое мнение на эту тему заключается в том, что конфигурация xml снижает ясность кода, особенно в больших системах.

Аннотации типа @Component делают вещи еще хуже. Это заставляет разработчиков делать объекты изменяемыми, поскольку зависимости больше не могут быть окончательными, учитывая необходимость предоставления конструкторов по умолчанию. Зависимости должны быть либо введены через общедоступный сеттер, либо неуправляемы через @Autowired. [еще худшее внедрение зависимостей скомпрометировано с классами, которые создают их зависимости, я все еще вижу это во вновь написанном коде!]. Под неконтролируемым я подразумеваю, что в больших системах, когда доступно несколько реализаций (или дочерних элементов) этого типа, гораздо сложнее понять, какая из реализаций была @Autowired, - сложность, которая значительно усложняет исследование ошибок. Это также означает, что, предположительно, у вас есть профиль для тестовой среды, а другой - для производства, ваши производственные ошибки будут возникать только тогда, когда это наносит наибольший вред - на производстве, вместо того, чтобы обнаруживать ошибки в тестовой среде, или даже лучше, время компиляции!

Я придерживаюсь середины, где я объявляю свой класс (ы) конфигурации (конфигурация Spring на основе Java с использованием @Configuration)

Я объявляю все мои bean-компоненты явно в классе (ах) конфигурации. Я использую только @Autowired в классе (ах) конфигурации, целью является ограничение зависимости от Spring для класса (ов) конфигурации

@Configuration находится в определенном пакете, это единственное место, где выполняется весеннее сканирование. (Это значительно ускоряет время запуска в крупных проектах)

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

Сокращение возможностей изменения объектов после их создания, существенно уменьшает количество ошибок в большой системе, а также сокращает время на обнаружение ошибки, когда она существует.

Также кажется, что это заставляет разработчика лучше проектировать взаимодействие между различными частями системы. Проблемы и ошибки становятся все более и более ошибочными при компиляции, что сокращает потерянное время и повышает производительность.

Answer 7

Я действительно люблю писать с аннотациями, а не с XML. Согласно руководству Spring и последним версиям, XML и Аннотация достигли одного и того же результата.

Это мой список

Pro:

• Удалить ненужную строку из xml
• Упростите отладку кода: когда вы открываете класс, вы можете прочитать, что у вас есть в классе
• Более быстрая разработка, можно ли читать проект с 400 или более строками XML?

Минусы:

• Не является стандартной реализацией Java, но вы можете переключиться на использование @Inject, который является стандартным Java API, поэтому компонент остается Pojo
• Вы не можете просто использовать везде, дБ соединение и т. Д., Но это всего лишь мнение, я предпочитаю иметь место, где можно прочитать всю конфигурацию.

Answer 8

Вот немного опыта
Плюсы

• Упрощает настройку, поскольку мы можем просто использовать аннотацию @Autowire
• Не хочу использовать методы установки, поэтому класс будет более чистым

Против

• Плотная связь с XML-файлом, хотя мы используем DI
• Трудно найти реализацию (но если вы используете хорошие идентификаторы, такие как intellij, вы наверняка сможете от этого избавиться)

Что касается моего личного опыта, я не так часто использовал аннотацию @AutoWire, но в тестовых примерах.

Answer 9

Насколько я понимаю, @Autowired лучше всего использовать, обращаясь к справочнику по интерфейсу и используя его функции переопределения, но я обнаружил, что проблема заключается только в том, что он иногда присваивается нулю во время выполнения.