DTO should be used with care. Generally we decide case by case, whether we shall introduce DTO layers which generates more complexity, or whether we work directly with the domain objects (DOs). The list below will assist us by our decission.
When can i use DomainObjects(DOs) direct to visualize details in the GUI?
Case 1:
you can do it (and shall do it) by readonly views and if the domain object doesn't need to go back to the database. During this process the client may change values of the domain object if necessary. The only condition: The domain object is not returned to the database.
Case 2:
If other software parts use the same service needing the whole content of a domain object. In this case you may get and use the whole domain object. But if you wanna change some values of it and store it back into the database, then you'll need new objects called: prefixDTOData. why that? Because otherwise we would force the service which writes the attributes into database to iterate over the whole domain object looking and comparing for changes before writing down in the database.
When shall i better use DTOs?
Case 1:
Use DTO's if the domain object is huge, but you just need a few attributes of it! For large domain objects, in which the client visualize, change or display only a few of its attributes. In this case we recommend to use the notation: prefixDTO. This is the object which the client uses to do its works. The service gets the Domain Object, creates the DTO and gives it back. If this DTO is used in a wizard or kind of formular in which the user may type something in setting values, which means that you have to store the typed information into database, then you should use in addtion to the DTOs new objects called: prefixDTOData. why that? Because otherwise we would force the service which writes the attributes into database to iterate over the whole domain object (remember that the domain object is huge) looking and comparing for changes before writing down in the database.
Case 2:
Use DTOs if the client has to show fields from different domain objects. In this special case you may consider putting all the needed attributes together already in the database creating the DTO in the server which is passed to the service going to the client. The client creates analoque to Case 1 a prefixDTOData an gives it back to the service. the reasons are the same as in explained in Case 1.
What are the disadvantages of DTOs?
You have/create additional complexities, which means that if things has to be changed, you have to make the changes everywhere in your code.
😱👇 PROMOTIONAL DISCOUNT: BOOKS AND IPODS PRO 😱👇
Be sure to read, it will change your life!
Show your work by Austin Kleon: https://amzn.to/34NVmwx
This book is a must read - it will put you in another level! (Expert)
Agile Software Development, Principles, Patterns, and Practices: https://amzn.to/30WQSm2
Write cleaner code and stand out!
Clean Code - A Handbook of Agile Software Craftsmanship: https://amzn.to/33RvaSv
This book is very practical, straightforward and to the point! Worth every penny!
Kotlin for Android App Development (Developer's Library): https://amzn.to/33VZ6gp
Needless to say, these are top right?
Apple AirPods Pro: https://amzn.to/2GOICxy
😱👆 PROMOTIONAL DISCOUNT: BOOKS AND IPODS PRO 😱👆
