Spring автоустановщик/конструктор PROs и CONs

При использовании @Autowired (а не xml-конфигурации), может ли кто-то сравнить преимущества привязки набора/конструктора и недостатки?

См. следующие примеры:

public class Example{
   private Logger log;
   // constructor wiring
   @Autowired 
   public Example(Logger log){
      this.log = log;
   }
}

public class Example{
   // setter wiring
   @Autowired 
   private Logger log;
}

Ответы

Ответ 1

Это все зависит от предпочтений.

Spring хмурится при инсталляции конструктора или, по крайней мере, используется, потому что, таким образом, появляются круговые зависимости, и их трудно управлять (для этого нужен B в конструкторе, B - A в конструкторе).

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

Я предпочитаю инъекцию поля.

Ответ 2

Играя адвоката дьявола долго после того, как все проголосовали за инъекцию в поле, вот некоторые преимущества для использования конструкторов, собранных из сотрудников опроса вокруг:

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

Мне все равно нравится, что если мне нужно аннотированное поле в другом классе, я могу просто сделать копию-вставку и сделать с ней, а не добавлять ее в конструктор, но это только вторичное рассмотрение.

Ответ 3

Конкретная причина аннотирования сеттеров: сеттеры могут затем сохранить ссылки bean на статические переменные.

Ответ 4

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

С помощью autowiring единственная причина, по которой я могу думать, - избежать проблемы с круговой зависимостью. Если A имеет B, то он имеет автоуровневую зависимость от конструктора, а B имеет то же самое для A, мы не можем создать экземпляр любого из них. Предоставление одной зависимости сеттера может помочь в этом.