Spring @Пользовательское использование

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

Для меня вот что мне нравится/не нравится в Spring и автоматической проводке.

Плюсы:

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

Минусы:

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

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

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Конфигурация @Configuration находится в определенном пакете, и это единственное место, где выполняется сканирование Spring. (Что значительно ускоряет время запуска в больших проектах)

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

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

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

Ответ 7

Вот некоторые примеры
Преимущества

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

против

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

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

Ответ 8

Мне очень нравится писать с аннотациями, а не XML. Согласно руководству Spring и последним версиям, XML и Annotation достигли того же результата.

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

Pro:

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

Минусы:

  • Не стандартная реализация Java, но вы можете переключиться на использование @Inject, который является стандартным Java Api, поэтому bean остается Pojo
  • Вы не можете просто использовать везде, db-соединение и так далее, но это только мнение, я предпочитаю иметь место, где читаются все настройки.

Ответ 9

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