是否应该使用实体类作为请求主体

Question

假设我必须保存一个实体，在本例中为 Book。我有下一个代码：

@RestController
@RequestMapping("books")
public class BookController {
    
    @Inject
    BookRepository bookRepository;
    
    @PostMapping
    public Book saveBook(@RequestBody Book book) {
        return bookRepository.save(book);
    }
}

我的实体 Book 是一个持久性实体：

@Entity(name = "BOOK")
public class Book{

    @Id
    @Column(name = "book_id")
    private Integer id;

    @Column(name = "title")
    private String title;

    (get/sets...)
}

问题是：在@RequestBody控制器层使用我的持久性实体是一种不好的做法吗？或者我应该创建一本书 DTO 并将其映射到服务层中的持久性类？什么更好，为什么？

Answer 1

您应该创建一个 DTO 类并将其映射到持久性类。请参阅此规则说明。指定的原因是

\n

\n

如果将持久对象用作使用@RequestMapping注释的方法的参数，则可以通过特制的用户输入将意外字段的内容更改到数据库中

\n

\n

除此之外，使用 DTO，我们可以省略一些我们不希望在表示层中出现/可见的持久对象属性。

\n

您可以将 DTO 类映射到控制器本身的持久性实体，如下所示。

\n

@RestController\n@RequestMapping("books")\npublic class BookController {\n    \n    @Autowired\n    BookRepository bookRepository;\n\n    @Autowired\n    ModelMapper modelMapper\n    \n    @PostMapping\n    public Book saveBook(@RequestBody BookDTO modelBook) {\n        Book book = this.modelMapper.map(modelBook, Book.class);\n        return bookRepository.save(book);\n    }\n}\n

\n

ModelMapper 是一个框架，用于执行 DTO 到实体的映射，反之亦然。检查ModelMapper 网站。

\n

您可以参考答案和评论以获取有关相同内容的更多信息。

\n

Answer 2

是的，这是一个非常糟糕的主意。

实体代表数据库中维护的持久数据并封装企业范围的业务规则。另一方面，DTO 是一个愚蠢的对象 - 它只保存属性并具有 getter 和 setter，但没有任何其他任何意义的逻辑。DTO 仅用于将数据从应用程序的一个子系统传输到另一个子系统。

想象一下有一个新的要求来添加新的多对多关系：

@Entity(name = "BOOK")
public class Book{

    @Id
    @Column(name = "book_id")
    private Integer id;

    @ManyToMany
    Set<Student> likes;

... 
} 

数据库的此类更改也会更改 API。