Где будет правильно расположить методы конвертации дто -> ентити и наоборот?
Думал над несколькими вариантами:
- Разместить прямо в дто в каждом.
- Создать отдельный класс DTOUtils и все туда скинуть ( но тогда там вперемешку будут методы конвертации всех классов )
- Сделать пакет dtoutils и там создать много классов ( для каждого дто свой, они будут только хранить дто методы и все )
Третий вариант выглядит как самый благоразумный, но создавать отдельный класс для одного метода это как-то не очень
P.S. Можно ли в классе-маппере разместить репозиторий, если это необходимо для конвертации ДТО-Ентии? Или это плохой тон?
Ответы (1 шт):
Одним из правил "чистой архитектуры" является разделение логики по уровням. Отделение абстракции от реализации. Ваши Entity - конкретная реализация того как вы работаете с БД. Сейчас вы работаете с JPA, через месяц захотите использовать например JDBC для более тонкого управления работой с БД, через 2 месяца вообще решите отказаться от SQL и перейти на NoSQL, так вот такие "переходы" не должны вызывать больших трудозатрат.
Если в вашей логике вы работаете только с DTO и Entity определите интерфейс
public interface IUserRepository {
UserDto findById(Long userId);
List<UserDto> findAll();
}
Это простой пример разграничения логики. В реализации IUserRepository вы можете исползовать UserEntity, репозитории от JPA, так же на этом уровне вы можете определить маппер для конвертации Entity в DTO для User. Таким образом ваша бизнес-логика не будет зависеть от способа хранения данных и при переходе единственное что вам необходимо будет изменить - реализацию вашего IUserRepository