Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Can DTO be replaced by domain object?

 
Ranch Hand
Posts: 205
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Domain objects mostly provide one to one mapping with the real world objects that we identify from the use case analysis. Whereas the DTO's are the objects that help in encapsulating the data required by the presentation layer. Now since the data required by the presentation layer may be very complex involving several different types of domain objects, then it must be beneficial to use DTO's. And the domain objects are used by the business layer to process business logic and provide persistence. when DTO's and Domains have altogether different purposes then how ca we replace the DTO's by the Domain objects?

Can someone put a some light on how to use DTO's and domain objects.
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Domain objects mostly provide one to one mapping with the real world objects that we identify from the use case analysis.



Not neccessarily. And in many cases domain/business objects do NOT map one-to-one with real-world concepts.

Whereas the DTO's are the objects that help in encapsulating the data required by the presentation layer. Now since the data required by the presentation layer may be very complex involving several different types of domain objects, then it must be beneficial to use DTO's.



While designing three-tier applications, including objects for data transfer is beneficial and usually required.

And the domain objects are used by the business layer to process business logic and provide persistence. when DTO's and Domains have altogether different purposes then how ca we replace the DTO's by the Domain objects?



The purpose of data transfer objects is to move data from Presentation-tier to Business-tier.

The purpose of domain/business data objects is to contain data needed for domain/business logic and/or to be stored
in application's database.

To attempt to replace data transfer objects with the actual domain/business objects is not a good idea, and conflicts with best practices of three-tier programming.
 
shukla raghav
Ranch Hand
Posts: 205
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Jimmy.

It means both DTO and domain objects are equally important but what about situations where a domain object can serve the purpose for the DTO why to create additional classes, is it not a redundant activity.

 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are welcome.

Yes, data transfer objects and domain/business objects are equally important.

In some situations, it may be possible to use the actual domain/business data object in the Presentation-tier (View) and this may seem like an "efficient" and "time-saving" design. However, you may risk corrupting the domain/business data object model by having to support View and Presentation-tier requirements, i.e. non-business requirements. Either as system is initially designed or in future as things change.

As mentioned in my earlier post, the data transfer object and the domain/business object have different purposes. Attempting to handle these effectively and efficiently with a single Class design conflicts with good design practices, the reasons for DTO design pattern, etc. If you can do it and consider and address system extensibility, scaleability, manageability, maintainability requirements for the coming three to five years, then yes, it may be a redundant activity and an exceptional situation.

Either way, if you can do it once, this doesn't mean that you should do it every time. Each system is different and will have different business requirements and different presentation requirements. Personally, the extra time needed to write code for DTO classes is trivial.

When the business application needs to support multiple Views, e.g. PDA, HTML browser, Desktop application, command-line, each one with its own set of Presentation-tier requirements, would you still be able to use a single domain/business object class design and use it as a DTO for all Views?



 
shukla raghav
Ranch Hand
Posts: 205
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

When the business application needs to support multiple Views, e.g. PDA, HTML browser, Desktop application, command-line, each one with its own set of Presentation-tier requirements, would you still be able to use a single domain/business object class design and use it as a DTO for all Views?



Thanks alot the above statement you made, cleared the picture for me, as in i understood what extensibility and flexibility might do to the application in the future !!!
 
Beauty is in the eye of the tiny ad.
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!