I would like to understand the use of an DTO with an Entity

Question

I wonder if my reasoning is correct regarding the use of a DTO

Following this logic, I am correct in using a DTO?

@Controller
@RequestMapping("/")
public class CadastroController
{
    private final CadastroRepository cadastroRepository;

    @Autowired
    public CadastroController(CadastroRepository cadastroRepository)
    {
        this.cadastroRepository = cadastroRepository;
    }

    @RequestMapping(method = RequestMethod.POST)
    @ResponseBody
    public void save(final CadastroDTO cadastroDTO)
    {
        CadastroEntity cadastroEntity = new CadastroEntity();
        cadastroEntity.setNome(cadastroDTO.getNome());
        cadastroRepository.save(cadastroEntity);
    }
}

public class CadastroDTO
{
    @Getter
    @Setter
    private String nome;
}

@Entity
@Table(name = "cadastro")
public class CadastroEntity implements Serializable
{
    @Id
    @GeneratedValue
    @Getter
    private Long id;

    @Getter
    @Setter
    private String nome;
}

If yes, I should use DTO only to store the information without the risk of changing the information in the database as it would with an entity?

Answer 1

In my view, your application is correct.

Traffic an instance of Entity out of the Controller it is not usually a good idea to allow code to be written that tries to change it in an inappropriate way or that ends up doing so in unexpected places (for example, by accidentally triggering the loading of a Lazy load), possibly after the commit has been made or when forcing a transaction scope not quite defined. Also, not always the contents of a Entity will be what the screen/functionality in question needs, can have more or less information, which means that there would be some violation of encapsulation in this case and the lack of an abstraction layer.

These above problems can obviously be fixed when programming up all these things with due care and attention. But by imposing this restriction of not exporting to Entity, these types of transaction and encapsulation problems Entity, generally disappear and the development of the application is much easier and less prone to programming errors.

However, something has to be exported to load the data referring to the operation performed, and for that is that the DTO serves and you seem to be using it properly. And that’s just the purpose of DTO, to transport data back and forth. Therefore, you carry in it whatever the operation in question is to use.

Note that the DTO you receive in your controller parameter does not need to be the same as the one you return in it. The DTO of the parameter contains the data received browser/user, while the return DTO contains the data to be envoys to the browser/user.

And obviously, if it’s something the browser doesn’t need to report, no parameters are necessary. If it is something where just the fact that the answer was not an exception thrown is sufficient, a return void is fine.

Furthermore, congratulations on your code. As far as I’m concerned it’s perfect, I have nothing to criticize it for. That’s very rare to see here at Sopt.