Пользовательский Spring Boot Starter с общими компонентами
Мы запускаем несколько загрузочных приложений Spring, основанных на тех же принципах, например:
- регистрация событий в базе данных.
- общий способ справиться с исключением (@ControllerAdvice)
- использование MDC для освещения наших журналов
- и больше.
Сегодня мы основываем наши приложения на родительском приложении Spring Boot. Он работает довольно хорошо, но кажется лучше использовать механизм Spring Boot Starter.
Некоторые вопросы о лучших практиках Spring Boot Starter:
- Можно ли определять некоторые @Controller или @Service в начальной зависимости?
- Можно ли определить общую обработку исключений / ошибок с помощью @ControllerAdvice в стартере?
- Если аннотации @Conditional ... не используются, можно ли сделать следующее?
Сервисный интерфейс
package net.mytest.boot.starter;
public interface Tooling {
void log(String message);
}
Внедрение услуги
package net.mytest.boot.starter;
// Is service is "allowed" inside a starter ?
@Service
public class ToolingImpl implements Tooling {
Logger log = LoggerFactory.getLogger(Tooling.class);
@Autowired
RepositoryLog repositoryLog;
public void log(String message) {
log.debug("Logging in DB " + message);
EntityLog entityLog = new EntityLog(UUID.randomUUID().toString(), message);
repositoryLog.save(eLog);
}
}
Конфигурация услуги
package net.mytest.boot.starter;
@Configuration
@ComponentScan("net.mytest.boot.starter")
@EntityScan("net.mytest.boot.starter.db")
@EnableJpaRepositories
public class ToolingAutoConfiguration {
// If @Service is not used, this allows autowiring Tooling
// @Bean
// public Tooling toolingConfig() {
// return new ToolingImpl();
// }
}
В этом примере ToolingAutoConfiguration используется обоими способами: - Определение конфигурации Spring Boot Starter (@Configuration, @ComponentScan ..) - Оказываем услугу (Оснастка)
Если мы используем его только для определения нашей стартовой конфигурации, имеет ли смысл предоставлять некоторый класс AutoConfiguration без каких-либо @Bean или @Service?
Только стартовая конфигурация
package net.mytest.boot.starter;
@Configuration
@ComponentScan("net.mytest.boot.starter")
@EntityScan("net.mytest.boot.starter.db")
@EnableJpaRepositories
public class ToolingAutoConfiguration {
}
Ответы 1
Лучший способ узнать, как создавать стартеры с автоконфигурацией, - это проверить официальные стартеры весенней загрузки. Например, автоконфигурация для веб-стартер весенней загрузки.
Большинство ваших вопросов основаны на мнениях, и на них действительно нет правильного ответа. Я выскажу свое мнение, основанное на моем опыте реализации автоконфигураций.
Is it ok to define some @Controller or @Service in a starter dependency?
Я лично хотел бы сохранить имплантации как можно более чистыми из Spring (избегайте, если они действительно не нужны). Просто объявите реализации как @Bean в своей конфигурации. Таким образом, если вам нужно добавить условия (которые могут потребовать учета нескольких компонентов) позже, вы можете сделать это из централизованного места, а не копаться в каждом отдельном классе.
Is it ok to define common exception/error processing using @ControllerAdvice in a starter?
Я бы сказал нет. Причина в том, что @ControllerAdvice имеет параметры, позволяющие указать, когда следует применять совет контроллера. Что делать, если пользователи стартера не хотят применять совет ко всем контроллерам или они хотят, чтобы применялись разные рекомендации? Я бы рассмотрел более гибкий подход, возможно, абстрактный класс, который пользователи могут расширять?
If not using the @Conditional... annotations, is it ok to do the following?
Условные выражения обычно используются, когда автоматически настроенные компоненты могут иметь нежелательные побочные эффекты для существующего приложения, требовать, чтобы другие компоненты функционировали, или должны быть включены / выключены в зависимости от значений свойств. Это полностью зависит от вас, чтобы настроить все, что необходимо, и нести ответственность за любые побочные эффекты.
В целом, из того, что я вижу, вам может даже не понадобиться автоконфигурация. Что вам может понадобиться, так это набор классов конфигурации, которые можно поместить в общую библиотеку, которую можно импортировать с чем-то вроде @Import индивидуально и при необходимости настраивать пользователем. Настоящая мощь автоконфигурации скрывает сложность настройки нескольких компонентов, которые работают вместе, устраняя все побочные эффекты и имея возможность переключаться с одной автоконфигурации на другую. Аспект гибкости больше контролируется автором автоконфигурации, чем пользователем.