Spring Boot：DTO外键转实体的操作位置与最佳实践探讨

我正在使用Spring Boot开发REST服务，在将JSON请求/DTO转换为对应实体时遇到了问题，尤其是当实体包含其他实体引用的场景。举例来说，我们有以下对象：

data class BookEntity(
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Int?,

    val name: String,

    @ManyToOne
    @JoinColumn(name = "author_id")
    val author: AuthorEntity,
)

data class AuthorEntity(
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Int?,

    val name: String,
)

data class BookRequestDto(
    val name: String,
    val authorId: Int,
)

应用采用控制器-服务-仓库分层架构，我了解到DTO→实体的转换应在控制器层完成，再将实体传递给服务层。但要将BookRequestDto转换为BookEntity，需先根据给定的authorId从仓库获取对应的AuthorEntity。我的问题是：具体应该在哪个层执行这一操作？

若服务层仅接收实体，似乎应在控制器层获取Author实体，但这意味着BookController需要依赖AuthorService，我不确定这是否符合最佳实践。

以下是我的实现示例（使用扩展函数完成DTO/实体转换）：

@RestController
@RequestMapping(path = ["/books"])
class BookController(
    private val bookService: BookService,
    private val authorService: AuthorService,
) {
    @PostMapping
    fun createBook(@RequestBody bookDto: BookRequestDto): ResponseEntity<BookResponseDto> {
        val author = authorService.get(bookDto.authorId)
        val bookEntity = bookDto.toBookEntity(author = author)
        val createdBook = bookService.create(bookEntity)
        return ResponseEntity(createdBook.toBookResponseDto(), HttpStatus.CREATED)
    }
}

这种做法是否常见？在控制器中注入多个服务是否属于不良实践？我必须在某处访问作者仓库，但不确定最佳位置，是否有更好的实现方式？

1. 当前实现并非不良实践 #

控制器注入多个服务是实际开发中常见的场景，只要控制器的职责保持在接收请求、参数校验、DTO转换、调用服务、返回响应这个核心范围内，就没有问题。你的代码逻辑清晰，没有违反单一职责原则，这种写法在很多项目中都能见到。

2. 更优方向：将实体构建逻辑移至服务层 #

如果不想让控制器依赖AuthorService，可以调整分层职责，让服务层统一处理实体的构建与业务逻辑：

• 修改BookService的create方法，直接接收BookRequestDto而非BookEntity
• 在BookService内部调用AuthorService获取作者实体，完成BookEntity的组装和持久化

示例代码如下：

// BookController
@RestController
@RequestMapping(path = ["/books"])
class BookController(
    private val bookService: BookService,
) {
    @PostMapping
    fun createBook(@RequestBody bookDto: BookRequestDto): ResponseEntity<BookResponseDto> {
        val createdBook = bookService.create(bookDto)
        return ResponseEntity(createdBook.toBookResponseDto(), HttpStatus.CREATED)
    }
}

// BookService
@Service
class BookService(
    private val bookRepository: BookRepository,
    private val authorService: AuthorService,
) {
    fun create(bookDto: BookRequestDto): BookEntity {
        val author = authorService.get(bookDto.authorId)
        val bookEntity = bookDto.toBookEntity(author)
        return bookRepository.save(bookEntity)
    }
}

这种方式的优势在于：

• 控制器职责更纯粹，只处理HTTP相关逻辑，不关心实体构建的细节
• 服务层统一封装业务逻辑（包括关联实体的获取与组装），符合分层架构的设计原则
• 后续业务逻辑变更时，只需修改服务层，无需改动控制器，降低耦合度

3. 额外优化：使用DTO转换工具简化代码 #

可以引入MapStruct、ModelMapper等工具，减少手动编写toBookEntity这类转换函数的工作量，提升代码可维护性。以MapStruct为例，可定义转换器接口自动处理基础字段映射，关联实体的获取则通过依赖注入服务完成。

内容的提问来源于stack exchange，提问作者FinnCoal