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

Question

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

Navigation

#1 by (4 votes)

3

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

Following this logic, am I 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, should I use the DTO only to store the information without the risk of changing the information in the database as would happen to an entity?

java

asked by anonymous 30.12.2016 / 18:35

1 answer

What is the difference between the 2 parameter passes? [duplicate] Executing text as code in VBA

score 4 · Accepted Answer

In my opinion, your application is correct.

Traffying an instance of Entity out of Controller is often not a good idea because it allows you to write code that attempts to change it improperly or that you end up doing it in unplanned locations (for example, accidentally trigger the loading of a lazy load ), possibly after the commit has been made or by forcing a not very well defined transaction scope. Also, not always the content of a Entity will be what the screen / functionality in question needs, and may have information of more or less, which means that there would be some encapsulation violation in this case and the lack of a layer of abstraction.

These problems, of course, can be corrected by scheduling all these things with due care and attention. But by imposing this restriction of not exporting% w / o%, these types of transaction problems and% wrapper encapsulation usually disappear, and application development becomes much easier and less prone to programming errors. / p>

However, something has to be exported to load the data for the operation performed, and this is what the DTO serves and you seem to be using it properly. And it is only that the purpose of the DTO, to carry data from one side to another. Therefore, you carry in it what the operation in question will use.

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

Of course, if this is something the browser does not need to report, then no parameter is required. If it is something where only the fact that the response was not a thrown exception is sufficient, a Entity return is good.

No, congratulations on your code. In my opinion, it's perfect, I have nothing to criticize about it. This is very rare to see here in SOpt.