Лучшая практика извлечения DTO и объекта с услугами и DAO при использовании Hibernate

Question

** 1. Использование сервиса: когда вы видите учебник весенней зимы, все говорят, что для сущности (например, User в моем случае) вы должны иметь репозиторий под названием UserRepository с такими методами, как find, findAll, delete и т. Д. Обычно UserRepository расширяет базовый репозиторий интерфейс.

Затем вы должны добавить UserService, который вводит UserRepository.

a. Должен ли я иметь интерфейс UserService, который реализуется с помощью UserServiceImpl? С моей точки зрения он не добавляет никакой ценности для этого. Я могу использовать UserService и использовать возможность Spring создавать прокси-сервер, используя GCLIB вместо JDKInterfaces.

b. Правильно ли написать UserService, скопировав каждый метод из UserRepository и делегируя его в @Autowired репозиторий, а затем добавить любой другой бизнес-метод?

c. Если у моего UserService нет каких-либо бизнес-методов, он просто делегирует все в UserRepository, могу ли я просто пропустить UserService и получить доступ непосредственно к UserRepoisitory с моего уровня REST?

d. Предположим, что у меня также есть объект Address. Пользователю нужен адрес при сохранении (он является обязательным для одного). Можно ли из UserService внедрить в него как UserRepository, так и AddressRepository, настроить там отношения, а затем вызвать сохранение в каждом репозитории? (Не хочу использовать каскадные упорствовать, я хочу знать, как бы я без него, так как в некоторых ситуациях вы не можете использовать каскадное)

2. DTO использование: Если вы хотите, чтобы прочитать данные, вы можете получить сущности или получить DTO непосредственно через JPQL (или критерии, я предпочитаю JPQL).

a. С моей точки зрения, я бы всегда использовал DTO вместо того, чтобы получать данные. Это потому, что я считаю, что SQL прост, и если мне нужно подумать о слиянии, отсоединении, подключении и т. Д., Я пропущу всю простоту SQL, а ORM становится врагом с точки зрения производительности и сложности. Поэтому я бы всегда использовал DTO, когда я читал данные и объекты, когда я изменяю данные. Как вы думаете?

b. Я хочу вернуть все столбцы из объекта User. Можно ли использовать UserDTo, или я преувеличиваю и должен просто вернуть объект User? Я на это 50% - 50%.

c. Я хочу частично вернуть некоторые столбцы от пользователя. Здесь я на 75% DTO и 25%. Как вы думаете?

d. Я хочу вернуть некоторые столбцы User и некоторые столбцы Address. Здесь я 100% для DTO (хотя я мог бы просто присоединиться к адресу Fetch Address). Как вы думаете?

С наилучшими пожеланиями,

Answer 1

Я отвечу на них один за другим:

1.а) Да, это имеет смысл. Уровень обслуживания - это транзакционная граница, и именно там вы представляете бизнес-логику внешнему миру через интерфейс, ориентированный на курс.

1.b) Нет, это не так.UserService определяет бизнес-методы, а не методы доступа к данным.

1.c) Я все равно буду пользоваться Сервисом.

1.d) Конечно, это так. Вам не нужно вызывать Сервисы по имени объекта. Назовите его бизнес-логикой, что они выражают.

2.a) Мое правило прост: объекты, когда вы планируете модифицировать и DTO для прогнозов только для чтения.

2.b) То же, что и 2.a.

2.c) То же, что и 2.a. If you need to modify the fetched data later, then use subentities.

2.d) То же, что и 2.a. Если вам нужно изменить данные, используйте сущности или сущности. В противном случае, DTO для прогнозов только для чтения.