Supongamos que tengo que guardar una entidad, en este caso, Libro. Tengo el siguiente código:
@RestController @RequestMapping("books") public class BookController { @Inject BookRepository bookRepository; @PostMapping public Book saveBook(@RequestBody Book book) { return bookRepository.save(book); } }Mi entidad Libro es una entidad de persistencia:
@Entity(name = "BOOK") public class Book{ @Id @Column(name = "book_id") private Integer id; @Column(name = "title") private String title; (get/sets...) } La pregunta es: ¿es una mala práctica usar mi entidad de persistencia en @RequestBody de la capa del controlador? ¿O debería crear un libro DTO y asignarlo a mi clase de persistencia en una capa de servicio? ¿Qué es mejor y por qué?
Debe crear una clase DTO y asignarla a una clase de persistencia. Consulte esta descripción de la regla para lo mismo. El motivo especificado es
si se usa un objeto persistente como argumento de un método anotado con @RequestMapping, es posible, a partir de una entrada de usuario especialmente diseñada, cambiar el contenido de campos inesperados en la base de datos
Aparte de esto, usando DTO podemos omitir algunas de las propiedades persistentes del objeto que no deseamos que estén presentes/visibles en la capa de presentación.
Puede asignar la clase DTO a la entidad de persistencia en el controlador como se muestra a continuación.
@RestController @RequestMapping("books") public class BookController { @Autowired BookRepository bookRepository; @Autowired ModelMapper modelMapper @PostMapping public Book saveBook(@RequestBody BookDTO modelBook) { Book book = this.modelMapper.map(modelBook, Book.class); return bookRepository.save(book); } }ModelMapper es un marco que hace el mapeo de DTO a Entidad y viceversa. Consulte el sitio web de ModelMapper .
Puede consultar la respuesta y los comentarios para obtener más información sobre el mismo.
Sí, es una muy mala idea.
Una entidad representa los datos persistentes mantenidos en una base de datos y encapsula las reglas comerciales de toda la empresa. Por otro lado, DTO es un objeto tonto: solo tiene propiedades y tiene getters y setters, pero ninguna otra lógica de importancia. Los DTO se utilizan solo para transferir datos de un subsistema de una aplicación a otro.
Imagine tener un nuevo requisito para agregar una nueva relación de muchos a muchos:
@Entity(name = "BOOK") public class Book{ @Id @Column(name = "book_id") private Integer id; @ManyToMany Set<Student> likes; ... }Tal cambio en la base de datos también cambiaría la API.