что лучше всего подходит для пакетного структурирования проекта Spring?

Не существует конкретной стандартной структуры, она будет варьироваться в зависимости от ваших потребностей.

1. Классы сущностей должны находиться в пакете домена, к которому нельзя добавлять имя класса. Это может быть Book.class, School.class и т. д.,
2. Поисковый запрос и ответ — это класс запроса и ответа. Он должен находиться в пакете контроллера. Это все конечные точки службы.
3. проверьте ссылку

В основном пакет SERVICE будет иметь все классы обслуживания, которые имеют бизнес-логику и соединяться с классами DAO, Controller будет иметь все остальные конечные точки, пакет Model будет содержать классы pojo.

1. Имя пакета для таблицы базы данных должно быть entity.

   Вот почему?

2. для Q2 и Q3 Структура упаковки

Надеюсь, это поможет, дайте мне знать :)

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

вопрос 1: какое должно быть имя пакета классов сущностей? сущность или модель?

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

Объект модели представляет данные в шаблоне MVC (Model View Controller). Сущностный объект представляет данные в шаблоне ORM (реляционное сопоставление объектов). Это может быть один и тот же объект. Или нет.

Итак, вы можете использовать Entity как класс Model, даже я понимаю, что это плохая практика. Если это ваш случай, возможно, вы предпочитаете использовать model в качестве имени пакета. Если нет, то entity — правильный выбор.

вопрос 2: где нужно сохранять Searchrequest и Searchresponse и другие классы ответа на запрос? в пакете модели или я должен создать другой пакет?

Эти классы очень коррелируют с пакетом контроллера. Итак, вы можете создать эти два пакета и поместить туда запрос и ответ, каждый в своем пакете:

controller.response
controller.request

вопрос 3: выходит какой-то стандарт для структурирования пакетов? (пожалуйста дайте ссылку)

См. этот ответ: Существуют ли передовые методы организации пакетов (Java)?< /а>

Нет строгих правил. Вы должны использовать имя, которое говорит само за себя (не нужно копаться в содержании классов, чтобы понять его значение). Это верно для микросервисов, веб-приложений, пакетных и любых приложений.

Я думаю, у меня много пакетов

Основная роль пакетов состоит в том, чтобы сортировать вещи в удобочитаемом виде.
Например, если у вас есть 2 или 3 класса по пакетам, вы можете задаться вопросом об их релевантности.
Аналогичным образом, если у вас есть 50 классов в пакет, вы также можете задаться вопросом, не следует ли вам разделить их на подпакеты.
Обратите внимание, что пакет также играет роль с точки зрения доступности: действительно, уровень доступа package private позволяет установить/уменьшить доступность класса или члена класса к классам текущего пакета. Это также может быть очень полезно с точки зрения дизайна и изоляции.

О ваших 3 вопросах:

вопрос 1: какое должно быть имя пакета классов сущностей? сущность или модель?

В Java entity обычно относится к объекту JPA (в целом в проекте Spring). В то время как model относится к более общей концепции, которая включает entity, но не только потому, что модель данных также может быть DTO объектами и любой специализацией данных вашей модели.
Если вы используете один слой объектов данных (сущности JPA, которые также используются как представление JSON), использование термина model имеет смысл. Если вы используете несколько уровней абстракции, пакет по уровню абстракции имеет больше смысла.

вопрос 2: где нужно сохранять Searchrequest и Searchresponse и другие классы ответа на запрос? в пакете модели или я должен создать другой пакет?

Если эти объекты проходят через каждый слой: в model, в противном случае, вероятно, в другом месте.

вопрос 3: выходит какой-то стандарт для структурирования пакетов? (пожалуйста, дайте мне ссылку)

3) Не совсем так, но, как правило, оно должно быть самоочевидным, очень ясным и общим для команды проектов, чтобы способствовать согласованности между проектами.