Предположим, у меня есть следующие классы:
@Entity
public class Book {
...
}
@Repository
public class BookRepositoryImpl implements BookRepository {
...
}
@Service
public class BookServiceImpl implements BookService {
...
}
@Entity
public class Author{
...
}
@Repository
public class AuthorRepositoryImpl implements AuthorRepository {
...
}
@Service
public class AuthorServiceImpl implements AuthorService {
...
}
Теперь я хочу сохранить книгу с автором.В мой BookService я передаю каким-то образом BookDto всю информацию, кроме автора, а в качестве второго параметра я передаю идентификатор автора.Теперь, чтобы сохранить мою книгу, мне нужно собрать сущность Book.Какой слой подходит для его создания?Я вижу несколько возможностей, но я не уверен, какой подход является правильным:
- в BookingService.createBook. Я могу вызвать AuthorService.findAuthorById и с этой сборкой Book, а затем передать ее в BookRepository
- Я могу передать всю информацию в хранилище и разрешить ей обрабатывать сущность, созданную этим, я имею в виду: в BookingService.createBook вызывает BookRepository.saveBookWithAuthor (Book book, Long authorId), и внутри этого метода я могу вызывать AuthorRepository.findAuthorById или вызывать AuthorService.findAuthorById, собирать сущность Book и сохранять ее
Какой подход правильныйодин и почему?Мне кажется, что логическое решение - это первое, однако мне не нравится идея смешивать сущности вместе с некоторой бизнес-логикой, которая может быть внутри моих сервисов.Есть ли шаблон для отделения бизнес-логики от технических решений?