Выгодно ли создавать бин 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);
}
....
}
В приведенном выше случае вместо автоматической проводки Foo
, Я могу сделать doSomeThing
статично и напрямую использовать Foo.doSomeThing(a,b)
Мне просто интересно, есть ли какое-либо преимущество в создании бина или есть какой-то недостаток в использовании статических методов, подобных этому?
Если они одинаковы, когда я должен пойти на бобы и когда я должен просто использовать статический метод?
3 ответа
Статические методы хороши для небольших служебных функций. Ограничением статического кода является то, что вы не можете изменить его поведение без изменения самого кода.
Весна, с другой стороны, дает вам гибкость.
IoC. Ваши классы не знают о точной реализации своих зависимостей, они просто полагаются на API, определенный интерфейсом. Все соединения указаны в конфигурации, которые могут отличаться для производства / тестирования / других.
Сила метапрограммирования. Вы можете изменить поведение ваших методов, просто пометив их (с помощью аннотаций в xml). Таким образом, вы можете обернуть метод в транзакции, сделать его асинхронным или запланированным, добавить пользовательские перехватчики AOP и т. Д.
Spring может использовать ваш метод POJO, чтобы сделать его конечной точкой для удаленного веб-сервиса / RPC.
http://docs.spring.io/spring-framework/docs/current/spring-framework-reference/html/
Методы в бобах Spring могут извлечь выгоду из внедрения зависимостей, тогда как статические методы не могут. Таким образом, идеальным кандидатом для статического метода является тот, который делает вещи более или менее независимо и не предполагает, что ему когда-либо понадобится какая-либо другая зависимость (скажем, DAO или служба)
Люди используют Spring не из-за каких-то узких специфических вариантов будущего, которые нельзя заменить статическими классами, DI или чем-то еще. Люди используют Spring из-за более абстрактных функций и идей, которые он предлагает "из коробки". Вот хорошая цитата из чьего-то блога:
Ниже приведены некоторые из основных преимуществ, предлагаемых Spring Framework:
- Spring включает программирование POJO. Spring позволяет программистам разрабатывать приложения корпоративного класса с использованием POJO. С помощью Spring вы можете выбирать свои собственные сервисы и систему постоянства. Вы программируете в POJO и добавляете к ним корпоративные сервисы с помощью файлов конфигурации. Вы строите свою программу из POJO и настраиваете ее, а остальное скрыто от вас.
- Весна обеспечивает лучшее кредитное плечо. В Spring больше работы можно выполнить с каждой строкой кода. Вы пишете код более быстрым способом и сохраняете меньше. Там нет обработки транзакций. Spring позволяет создавать конфигурационный код для обработки этого. Вам не нужно закрывать сеанс для управления ресурсами. Вам не нужно делать настройку самостоятельно. Кроме того, вы можете управлять исключениями в наиболее подходящем месте, не сталкиваясь с необходимостью управления ими на этом уровне, поскольку исключения не проверяются.
- Внедрение зависимостей помогает тестируемости. Spring значительно улучшает вашу тестируемость благодаря шаблону разработки, который называется Dependency Injection (DI). DI позволяет вам кодировать производственную зависимость и тестовую зависимость. Тестирование приложения, основанного на Spring, легко, потому что вся связанная среда и зависимый код перемещены в платформу.
- Инверсия управления упрощает JDBC. Приложения JDBC довольно многословны и требуют много времени. Что может помочь, так это хороший уровень абстракции. В Spring вы можете настроить метод JDBC по умолчанию с помощью запроса и анонимного внутреннего класса, чтобы уменьшить большую часть тяжелой работы.
- Весенняя согласованность. Spring - это сочетание идей в единое целое, а также общее архитектурное видение, способствующее эффективному использованию, поэтому гораздо лучше использовать Spring, чем создавать собственное эквивалентное решение.
- Основа на существующих технологиях. Основа Spring основана на существующих технологиях, таких как среда ведения журналов, платформа ORM, Java EE, таймеры JDK, Quartz и другие технологии, связанные с представлениями.
Во время модульного тестирования у вас больше гибкости, используя bean-компонент, потому что вы можете легко имитировать свои методы bean-компонента. Однако это не то же самое со статическими методами, где вам, возможно, придется прибегнуть к PowerMock (от которого я рекомендую вам держаться подальше, если можете).
На самом деле это зависит от глобальных правил проектирования вашего проекта: является ли эта функция внутренним инструментом (используйте статический) или скорее "модулем" (используйте bean-компонент)?
В общем, уже есть несколько ответов, описывающих преимущества использования Spring beans, поэтому я не буду на этом останавливаться. Но вот основные причины не использовать его:
- Вы (можете) получить гораздо больше гарантий во время компиляции
- Нет косвенного обращения, поэтому код легче отслеживать
- Вам не нужны дополнительные пружинные зависимости
Очевидно, что (3) верен только в том случае, если вы вообще не используете spring в своем проекте /lib.
Кроме того, (1) и (2) действительно зависят от того, как вы кодируете. И самое главное - иметь и поддерживать чистый, читаемый код. Spring предоставляет структуру, которая заставляет вас следовать некоторым стандартам, которые нравятся многим. Лично я этого не делаю из-за (1) и (2), но я видел, что в разнородных командах разработчиков лучше использовать это, чем ничего. Итак, если вы не используете Spring, вы должны следовать некоторым строгим правилам кодирования.