Насколько я понимаю, ваш вопрос касается, в частности, слоев и их использования на уровне logic. (Таким образом, уровни presentation и data не являются частью вопроса).
О PersonModel
Я не уверен, что вы имеете в виду под PersonModel и что он на самом деле делает, но на первый взгляд могу сказать, что обычно вам не нужно что-то подобное, что рано или поздно добавит дополнительное дублирование кода и затраты на обслуживание.
О PersonDto
DTO s, как следует из названия, действительно предназначены для передачи данных между клиентом (уровень presentation) и вашим API (уровень controller / boundary в пределах logic tier), которые используются для предоставления " дружественная к клиенту »презентация вашей доменной модели , чтобы как-то регулировать избыточную и недостаточную выборку (благодаря GraphQL это теперь почти не проблема). Таким образом, вашим классам бизнес-услуг вообще не нужно знать или иметь дело с DTO.
Кроме того, как вы уже упоминали, ради SRP бизнес-классы или дао-классы не должны иметь дело с дополнительным отображением данных (например, Dto <-> Model, Model <-> Entity) любым способом. Они уже выполняют определенную задачу на уровне логики c (ср. пограничный слой , сервисный уровень ).
О PersonEntity
Это то, что обычно представляет и сущность real из вашего проблемного домена и data уровня (например, таблица базы данных в СУБД или документ в № SQL). Так что
довольно часто называют классы сущностей без суффикса, например Entity. Просто используйте для него простое имя, например Person,
, чтобы классы сущностей содержали дополнительные аннотации (например, JPA), чтобы сделать их видимыми для ORM layer (например, Hibernate),
что классы сущностей не обязательно должны быть anemi c и фактически содержать некоторое дополнительное поведение (вероятно, то, что вы хотели сделать с вашим PersonModel классом) Например,
class Person {
Date birthday;
int getAge() { /* calculate age based on the birthday */ }
boolean isAdult() { /* getAge() >= 18 */ }
}
Заключение
Вариант использования: создание Person объекта
Hinflug (исходящий рейс)
[Client] --> (data: JSON) --> <Deserialization as `PersonDTO`> --> <DTO Validation> --> [PersonController] --> <AutoMapping to `Person` entity> --> [PersonService] --> [PersonDao] --> <ORM and JDBC> --> <Entity Validation> --> DB
Примечание: <Validation> также можно сделать в контроллере вручную, но обычно для автоматизации используется API проверки бинов этот процесс на заднем плане . Хорошо, что вы можете использовать API Bean Validation для проверки ваших DTO и сущностей (например, с Hibernate Validator ).
Rückflug (обратный рейс)
DB --> <ORM and JDBC> --> [PersonDao] --> [PersonService] --> <AutoMapping to `Person` entity> --> [PersonController] --> <AutoMapping `Person` entity to `PersonDTO`> --> <Serialization of `PersonDTO`> --> (data: JSON) -> [Client]