Как лучше всего разделить уровень службы / хранилища Spring Boot на отдельный проект Maven? - PullRequest
Новая
       47

Как лучше всего разделить уровень службы / хранилища Spring Boot на отдельный проект Maven?

0 голосов
/ 29 января 2020

Я работаю над приложением Spring Boot с шаблонами Thymeleaf для представлений, а также с классами Java в трех «ярусах»: Controller, Service и Repository. Я хотел бы переместить уровни Service и Repository в отдельный проект Maven (я называю это «уровень службы»), который приложение View / Controller может использовать как зависимость.

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

Каков наилучший способ выделить только службы и репозитории? Вот некоторые конкретные c пунктов для пояснения, но могут быть и другие вопросы Я не понял, что мне нужно спросить:

  • Какие стартеры и зависимости мне нужны в POM артефакта уровня обслуживания? spring-boot-starter-parent? spring-boot-starter-jdbc? Драйвер базы данных?

  • Помогают ли мне аннотации @Service и @Repository, если они находятся в артефакте уровня обслуживания?

  • Нужен ли аннотированный класс @SpringBootApplication в проекте уровня обслуживания, например, для запуска тестов? Как насчет spring-boot-maven-plugin? (Последнее, кажется, предотвращает фазу "mvn install".)

  • Где я могу разместить свойства моего источника данных, такие как URL JDB C? В application.yml в уровне обслуживания или в проекте уровня UX, который от него зависит?

Указатели на рабочий код, который разделен таким образом, приветствуются!

1 Ответ

0 голосов
/ 06 марта 2020

После долгих проб и ошибок я закончил с этим, и он работает:

service-tier - это проект Maven, содержащий аннотации @Service и @Repository.

  • Содержит зависимости spring-boot-starter-parent, spring-boot-starter-web, spring-boot-starter-jdbc, spring-boot-starter-security, а также драйвер базы данных. Также есть некоторые тестовые зависимости: JUnit, spring-boot-starter-test и spring-security-test. Это почти все зависимости, которые использует внешнее приложение, за исключением Thymeleaf и некоторых артефактов Webjars.

  • Я не знаю, делают ли аннотации что-нибудь для меня или нет, но я держал их в себе.

  • Через некоторое время я вспомнил, что у проектов Maven есть каталог test для классов и ресурсов, которые будут использоваться только в тестировании и не будут поставляться в комплекте с упакованным JAR или ВОЙНА. В этой структуре каталогов я поместил аннотированный класс @SpringBootApplication, а также application.yml с информацией о подключении к базе данных. Это используется при выполнении интеграционных тестов и не влияет на веб-приложения, которые зависят от уровня обслуживания.

Внешние приложения - это собственные проекты Maven. В каждом из них:

  • Они объявляют service-tier как зависимость.
  • Они также объявляют все зависимости Spring Boot. Многие излишни, но это не проблема с Maven. Дополнительные зависимости включают spring-boot-starter-thymeleaf и несколько других зависимостей Thymeleaf, а также несколько зависимостей от org.webjars, которые включают Bootstrap и JQuery.
  • Они также имеют свои собственные @SpringBootApplication аннотированные классы и application.yml. Это «реальные» конфигурации, а не только тестовые конфигурации.
  • Все классы @Controller, а также шаблоны Thymeleaf и файлы stati c и messages.properties находятся в этих интерфейсных проектах.
  • Конфигурация Spring Security (т.е. WebSecurityConfigurerAdapter экземпляров) находится в этих проектах. (UserDetailsService находится на уровне обслуживания.)

Это работает довольно гладко, пока я удостоверяюсь, что интерфейсные приложения всегда вызывают последнюю версию service-tier.

Одно интересное осложнение заключается в том, что приложение Spring Boot будет сканировать только классы обслуживания и хранилища в пределах своего собственного пакета Java. Изначально у меня был уровень обслуживания в иерархии пакетов, такой как "com.mycompany.servicetier", а внешние интерфейсы в пакетах, таких как "com.mycompany.appone" и "com.mycompany.apptwo". Мне пришлось переместить аннотированный класс @SpringBootApplication в каждом внешнем проекте на один уровень выше, до "com.mycompany", чтобы он обнаруживал классы уровня обслуживания "под ним" для внедрения зависимостей.

...