I am creating a fairly large application that uses the DAO / DTO design pattern to get data from a database Does. In the application, a special DTO "core data structure" has been created, in which it is referenced in the entire project. I am wondering if this project is a good practice to deeply integrate this DTO, or do I have some sort of conversion layer where I can convert the DTO into a non-DTO object?
I can see the reasons for this conversion layer and its opposite reasons. For example, if we have a conversion layer: 1) The huge change in DTO may be the cause of errors in the whole project, so due to the conversion layer, the error is separated by a point in the code. 2) I am able to add additional logic to the original data structure which can not be added to the DTO as it is automatically generated
However, I also see drawbacks to keep a conversion layer: 1) When DTO also changes, the DTO conversion code should be kept consistent. It adds another step that the programmer should be aware and therefore it is more likely 2) It also leads to code repetition, because for the most part, you are copying the accessories of the DTO.
What is the best way to go? What is the DTO everywhere or the conversion layer? Can anyone guide me in the right direction?
I thought the name's intent would be far away: data transfer object data transfer.
The idea behind DTO is that you use to cover the data that you are sending out of your domain model, for example, at the second level. You are not exposing your reasoning, you are just sending some data.
If your domain objects are DTOs, then you are exposing your domain argument outside your domain argument, or you have other domain logic or both of your domain objects apart from it.
I have been on projects that kept them separate and I have been on projects that mixed them. I really can not recommend blending them to mix your layers, like tie dye
Comments
Post a Comment