Разве выгодно создавать компонент Spring, когда я могу получить доступ к единственному статическому методу непосредственно с именем класса

Я думаю, что мое понимание весенних бобров немного сбито.

Я работал над своим проектом, и я думал об этой ситуации.

Скажем, у меня есть класс Foo

class Foo(){   
   public void doSomething(Object a , Object b){ // input parameters does not matter actually.
      //do something
   }
}

Если я использую этот класс в другом классе, например:

class Scheduler{
  ....
 @Autowired
 private Foo foo;

 someMethod(){
    foo.doSomeThind(a,b);
 }
  ....
}

В приведенном выше случае Вместо Autowiring Foo я могу сделать doSomeThing статическим и напрямую использовать Foo.doSomeThing(a,b)

Мне просто интересно, есть ли какое-то преимущество в создании компонента или если есть недостаток использования статических методов, подобных этому?

Если они такие же, когда я должен идти на весенний боб, а когда должен делать, я просто использую статический метод?

Ответы

Ответ 1

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

Spring, с другой стороны, дает вам гибкость.

IoC. Ваши классы не знают о точной реализации своих зависимостей, они просто полагаются на API, определенный интерфейсом. Все соединения указаны в конфигурации, которые могут отличаться для производства/тестирования/других.
Сила метапрограммирования. Вы можете изменить поведение ваших методов, просто пометив их (с помощью аннотаций в xml). Таким образом, вы можете обернуть метод в транзакции, сделать его асинхронным или запланированным, добавить пользовательские перехватчики AOP и т.д.
Spring может использовать ваш метод POJO, чтобы сделать его конечной точкой для удаленного веб-сервиса /RPC.

http://docs.spring.io/spring-framework/docs/current/spring-framework-reference/html/

Ответ 2

Методы в весенних бобах могут извлечь выгоду из инъекции зависимостей, тогда как статические методы не могут. Таким образом, идеальным кандидатом на статический метод является тот, который делает вещи более или менее независимо и не предвидится когда-либо нуждаться в какой-либо другой зависимости (например, DAO или Service)

Ответ 3

Люди используют Spring не из-за некоторых узких конкретных фьючерсов, которые не могут быть заменены статическими классами или DI или что-то еще. Люди используют Spring из-за более абстрактных функций и идей, которые он предоставляет из коробки. Вот хорошая цитата из блога Someone:

Ниже приведены некоторые из основных преимуществ Spring Framework:

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

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

Интенсивность инъекций помогает тестированию. Spring значительно улучшает вашу тестируемость с помощью шаблона проектирования под названием Dependency Injection (DI). DI позволяет кодировать зависимость производства и зависимость от теста. Тестирование приложения на основе Spring легко, потому что вся связанная среда и зависимый код перемещаются в структуру.

Инверсия управления упрощает JDBC. Приложения JDBC довольно многословны и требуют времени. Что может помочь, это хороший уровень абстракции. С Spring вы можете настроить метод JDBC по умолчанию с запросом и анонимный внутренний класс, чтобы уменьшить значительную часть тяжелой работы.

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

Основа существующих технологий. Основа Spring основана на существующих технологиях, таких как система ведения журнала, структура ORM, Java EE, таймеры JDK, кварц и другие технологии, связанные с просмотром.

Ответ 4

Практическое правило для меня таково: есть ли у этого вызова зависимости от чего-либо или от побочных эффектов, или это обязательно функция его аргументов (например, метод служебной программы String, который не может зависеть ни от чего другого)?

Поскольку вызов вашего метода не использует никакого возвращаемого значения, если таковое имеется, которое говорит мне, что вы вызываете его для побочных эффектов (хотя может быть возможность, когда это вызывается, чтобы вызвать исключение, или сделать поменять на файловую систему или кто что знает). Если это вызвано его побочными эффектами, я ожидаю, что это зависит от других вещей, которые Spring должен вводить. Так что это должен быть боб Spring.

Ответ 5

На самом деле это зависит от глобальных правил проектирования вашего проекта: является ли эта функция внутренним инструментарием (используется статический) или, скорее, "модулем" (используйте бин)?

В целом, уже есть несколько ответов, описывающих преимущества использования бобов spring, поэтому я не буду останавливаться на этом. Но вот основные причины не использовать его:

Вы можете получить гораздо больше гарантий во время компиляции
Направленности нет, поэтому легче отслеживать ваш код
Вам не нужны дополнительные пружинные зависимости

Очевидно, что (3) является правильным, только если вы вообще не используете spring в вашем проекте /lib.

Кроме того, (1) и (2) действительно зависят от того, как вы кодируете. И самое главное - иметь и поддерживать чистый, читаемый код. Spring предоставляет структуру, которая заставляет вас следовать некоторым стандартам, которые нравятся многим людям. Я лично не из-за (1) и (2), но я видел, что в разнородных командах разработчиков лучше использовать его, чем ничего. Таким образом, если вы не используете пружину, вы должны следовать строгим правилам кодирования.