Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • 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
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

Approach for using Data Transfer Objects

 
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Am facing problem in implementing DTOs. My DTO contains various fields like id, name, description, version, author, createdBy, lastmodifiedBy, creationData, LastMofificationDate etc. The scenario is, for one UI I need some of the fields of this DTO and for another UI I need all the fields.

Should I make two DTO's according to my UI requirement or make one DTO and set the non required fields to null?
If I make two DTO's is it a gud idea to use inheritance?

What approach should be taken while addressing this kind of problem?

Thanks & Regards,
Kapil
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll preface my response with my personal take on things: When you introduce a DTO to an architecture you've admitted that this whole object paradigm is not going to work in this spot and you're going to bridge some gap with plain old data structures. Once I've left the ideal land of OO goodness I get a little looser with the rules.

Making a custom DTO for each view is totally up to you. You trade the gain in efficiency moving only the fields you need against duplication in the code to define and load the DTOs. What's your own pain threshhold for duplication? For exatra fields? Duplication hurts me more than extra data, but your mileage may vary.

I don't think I'd go for inheritance because one DTO has all the fields of another plus a few more. Inheritance implies a lot about the relationship that may or may not be true over time. For example, the UI with fewer fields might suddenly get a few from a new source that the UI with more fields won't ever need.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stan raises a good point. Why do you use DTOs? DTOs are typically used to transfer data between remote systems - using them for transfer between local layers often is inferior to a more OO solution.

Still, if you want to go with DTOs, another solution would be to let one DTO implement different interfaces for the different views. The views only need to know about the interfaces, and you don't need to implement one DTO for every view. Google for the Interface Segregation Principle.
 
kapil Gupta
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your valuable feedback.

Since it is a client/server application (EJB) we need to pass information between client and Server and we are doing it using DTO
 
author
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another approach is to simply do the simplest thing possible, which is use the existing DTO which satisfies both needs. Unless you're suffering from a performance issue which would require you to create the second, smaller DTO then I don't see the need to do the extra work.

Develop the new DTO when you actually need to. Invest your time developing new business functionality that your stakeholders actually need, not tweaking an already sufficient design.

- Scott
 
kapil Gupta
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As you suggested, since performance is not an issue so making one big DTO makes sense. But still there is one more issue. My product is an OEM component with exposed set of APIs. There are certain fields in DTO like lastmodifiedDate or creationDate which is set by my API and passed to client after querying the database. But since the getter/setter methods of DTO are public, these fields can be sent by client also, when he creates/updates the entity (though my API wont process them). How can I avoid exposing the setter for these type of fields?
Regards,
Kapil
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sounds to me like you need to:
1. Create a new subclass which overrides the setters.
2. Indicate in the docs that the setters shouldn't be invoked. If your API doesn't process them, why do you care what your clients do? If they don't read the docs, and try to update things which obviously shouldn't be updated from their names, then the worst case scenario is that they've written extra code that they didn't need to.

- Scott
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have the DTO implement an interface that only contains the needed getters. Only publish the interface to the clients. (That's basically what I meant when I referred to the ISP above. You could also create a different interface for each type of client.)
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I had thought to hide the object with getters and setters inside another that has only getters and passes all the calls through. I think your interface idea is better, though.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!