Является ли Spring @Profile о методах хорошей практикой

У меня есть веб-приложение Spring Boot, предоставляющее услуги для отдыха.

Я спрашиваю себя, как правильно управлять профилями в Фильтрах. На самом деле в моем приложении 2 профиля: dev и prod (вы угадаете, что это означает ...)

В режиме prod мне нужно активировать больше фильтров, чем в режиме dev.

Класс конфигурации My Filters следующий:

@Configuration
public class FiltersConfig {

    @Bean
    public FilterRegistrationBean filterRegistrationBean(CompositeFilter compositeFilter){
        FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean();
        filterRegistrationBean.setDispatcherTypes(EnumSet.allOf(DispatcherType.class));
        filterRegistrationBean.addUrlPatterns("/*");
        filterRegistrationBean.setFilter(compositeFilter);
        return filterRegistrationBean;
    }

    @Bean
    @Profile("dev")
    public CompositeFilter devCompositeFilter(){
        CompositeFilter compositeFilter = new CompositeFilter();
        List<Filter> filtersList = new ArrayList<>();
        //filtersList.add(filter1());
        compositeFilter.setFilters(filtersList);
        return compositeFilter;
    }


    @Bean
    @Profile("prod")
    public CompositeFilter prodCompositeFilter(){
        CompositeFilter compositeFilter = new CompositeFilter();
        List<Filter> filtersList = new ArrayList<>();
        //filtersList.add(filter1());
        compositeFilter.setFilters(filtersList);
        return compositeFilter;
    }
}

Мои вопросы:

  • Это хорошая практика - добавлять @Profile в метод?
  • Есть ли способ заставить компилятор исключить классы, методы и т. Д., Аннотированные профилями, отличными от того, который задан как текущий? (Я не хочу, чтобы моя производственная банка / война была заполнена ненужным кодом!)
  • Обеспечивает ли весенняя загрузка более четкий способ организации профилей?

Спасибо.


spring-boot java maven spring spring-profiles
person Lucas.de    schedule 12.08.2016    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

config
    - Config1.java
    - Config2.java
    dev
        - WebConfig.java
        - DataConfig.java
    prod
        - WebConfig.java
        - DataConfig.java
person nowszy94    schedule 12.08.2016
comment
Как это согласуется с экосистемой Spring Boot? - person rougou; 26.07.2019

arrow_upward
4
arrow_downward

По моему собственному опыту, использование @Profile в любом java-коде - не лучшая идея. Вот почему я думаю, вам следует избегать его использования в коде:

  1. Вы всегда можете определить свойство, например my.feature-for-the-profile.enabled, для достижения той же цели с помощью профиля.
  2. Профили иногда расходятся, сохраняйте каждую изменяющуюся конфигурацию, поскольку свойства дают вам больше контроля над всем и везде.
  3. Spring Boot имеет четко определенную поддержку внешних свойств для конкретного профиля (например, application-prod.yml). Наличие профиля в базе кода усложняет задачу и иногда вводит в заблуждение.
  4. Вы можете изменить или переопределить с помощью свойств легче, чем обновлять и перекомпилировать код.
  5. ProfileCondition (как мета-аннотация на @Profile) не является SpringBootCondition, вы не можете использовать /autoconfig, чтобы определить, активирована она или нет.

Итог: определите профили для properties, а не для @Configurations или @Beans.

Если вы действительно хотите исключить тестовые материалы для своего производственного кода, ознакомьтесь с документацией spring-boot-devtools, если вы используете Maven, вы можете поместить все тестовые классы / ресурсы в отдельный модуль и пометить его как <optional>true</optional> или определить профиль maven для Это. Обратите внимание: наличие профиля maven и профиля загрузки Spring может сбивать с толку!

person tan9    schedule 22.08.2017
comment
Мой опыт также привел меня к такому же выводу. Определение свойства для каждой функции вместо использования @Profile делает код более читабельным и дает вам больше гибкости для смешивания и сопоставления функций в будущем. - person rougou; 26.07.2019

arrow_upward
0
arrow_downward

Это хорошая практика - добавлять @Profile в метод?

Это весенний подход к этой проблеме, поэтому он соответствует весенней экосистеме.

Есть ли способ заставить компилятор исключить классы, методы и т. Д., Аннотированные профилями, отличными от того, который задан как текущий? (Я не хочу, чтобы моя производственная банка / война была заполнена ненужным кодом!)

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

По моему опыту, профили проще

Обеспечивает ли весенняя загрузка более четкий способ организации профилей?

Не то, что я знаю, кроме подхода в ссылке выше

person farrellmr    schedule 12.08.2016
comment
Если я настраиваю свою сборку для исключения класса, это означает, что у меня установлен @Profile для класса, а не для метода, верно? Поскольку, если в одном классе у меня есть два метода, аннотированных с разными профилями, я предполагаю, что оба метода будут скомпилированы в файле .class независимо от профиля, используемого во время компиляции! Вот что меня смущает. - person Lucas.de; 16.08.2016
comment
Или используйте какую-то фильтрацию процесса сборки - я думаю, это переместит концепцию профиля в ваш процесс сборки - person farrellmr; 16.08.2016