• 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
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

Design Issue : Can I expose DTO through Interface?

 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I am working on an application where I am using DTOs to move data across different layers. I am working on a module and there is a differnet module which uses the functionality of one of the interfaces that I wrote. The other module basically uses the services of my module through a method exposed in an interface. This module has to send and receive data through the methods exposed in the interface. Can I have a DTO as a return type for these methods? I am not sure if I can create a DTO for the methods which other modules use. is it a good design to have a DTO exposed too?

Thanks,
Padma.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've seen it done, though it makes me uncomfortable. It links your public API to your most private inner workings which will make either one hard to change. I used a framework that had one family of data objects to communicate between business services and the persistence layer and another set to communicate between the presentation layer and the services. Good isolation, extra work to transform data objects, and makes one wonder why it used data objects in either place, let alone both.

That was pretty much the usual "it depends" answer. How are things working out in your system?
 
Ranch Hand
Posts: 375
Scala Monad
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree with Stan, in the usual answer "it depends".
DTOs are an easy way to interchange structured data, so I don't see a (big) problem on returning DTOs from a module Facade. On the other hand, DTOs doesn't come for free, and the clients now will depend on our module's exposed interface AND the DTOs: any change on them will impact your server and client.
As always, is a balancing act, depending on the complexity and the intended use of what you need to return... Maybe in an interface, probably is better to return interface types, but interfaces for DTOs seems an overkill.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On a slightly related topic, take a look at http://www.martinfowler.com/bliki/LocalDTO.html
 
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Padma if I understand your problem , you have a method in inteface
pubic xxx getUserDetails()
Now you want to return the value of this method in an DTO say UserTO
So your method becomes
pubic UserTO getUserDetails()
I would say there is nothing wrong with it be it might be case that this method is exposed to different modules.
So each module might have its own requirement and you do not want to expose all the fields to each module.
I would suggest in these cases extend your UserTO from another class lets say SuperTO which has the basic fields and then you can have UserTO, AddressTO etc extend from this SuperTO. And this SuperTO can be your return type.
Now for each calling module you need to expose only those fields though getter setters in your subclass which are required.
 
Story like this gets better after being told a few times. Or maybe it's just a tiny ad:
Enterprise-grade Excel API for Java
https://products.aspose.com/cells/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!