my dog learned polymorphism*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Domain Object Vs DTO.... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Domain Object Vs DTO...." Watch "Domain Object Vs DTO...." New topic
Author

Domain Object Vs DTO....

Senthil Narayanaswamy
Greenhorn

Joined: Apr 15, 2007
Posts: 4
Hi,
So far i have used seperate classes for Domain Object and DTO. I use Domain Object to persist to DB and DTO to be sent to UI. The thing came up is can, Domain Object and DTO be the same class. Personally, i prefer separate classes. However, i would like to hear from the folks here.
1. Did any of you used one class for Domain and DTO? Is Yes, advantages and disadvantages.

Thanks,
Senthil.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
1. Did any of you used one class for Domain and DTO? Is Yes, advantages and disadvantages.


Using a single business/domain class as a transfer object class makes sense if it is a data-oriented class, i.e. a class without business/domain logic. This will help keep the number of classes low and increase the maintainability of the application.

If you have 25 business/domain data-oriented classes, there is no need to then create 25 other classes just for sending data to Presentation tier. This is "trivial", redundant coding and a waste of precious time, in my opinion. The time spent could be better applied to handling other tasks and issues, e.g. like improving the business logic, security or preparing better documentation
[ December 01, 2008: Message edited by: James Clark ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
From http://martinfowler.com/bliki/LocalDTO.html


DTOs are called Data Transfer Objects because their whole purpose is to shift data in expensive remote calls. They are part of implementing a coarse grained interface which a remote interface needs for performance. Not just do you not need them in a local context, they are actually harmful both because a coarse-grained API is more difficult to use and because you have to do all the work moving data from your domain or data source layer into the DTOs.

[ December 01, 2008: Message edited by: Ilja Preuss ]

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Benoît de Chateauvieux
Ranch Hand

Joined: Aug 10, 2007
Posts: 183
Hi All,

Since JPA, Hibernate, Toplink and other ORM Frameworks, you can define your Domain Model with POJOs.
In this case, does-it make sense to add a DTO layer ?
I mean you can share those POJO entities with the presentation tier...

The only problem I can see deals with Lazy Loading.
As lazy loaded collections are implementations of the Collection interface specifics to the ORM framework, you need to have the ORM framework libraries in your presentation tier.

Your opinion ?

Beno�t


SCJP5 | SCBCD5 | SCEA5 Part 1
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Beno�t de CHATEAUVIEUX:
Since JPA, Hibernate, Toplink and other ORM Frameworks, you can define your Domain Model with POJOs.
In this case, does-it make sense to add a DTO layer ?
I mean you can share those POJO entities with the presentation tier...


That's exactly what we are doing, and it's working great. No, you don't need a DTO layer, unless you really have a distributed system, in which case you might need them to reduce the number of remote calls.



The only problem I can see deals with Lazy Loading.
As lazy loaded collections are implementations of the Collection interface specifics to the ORM framework, you need to have the ORM framework libraries in your presentation tier.


At least with hibernate, the lazy loading collections implement the java.util interfaces, so even the POJOs don't need to know about them, let alone the presentation layer.
Rajah Nagur
Ranch Hand

Joined: Nov 06, 2002
Posts: 239

1. Did any of you used one class for Domain and DTO? Is Yes, advantages and disadvantages.


In earlier days - DTOs made sense,when you had EJB tier (i.e. used entity beans for persistence). The most preferred j2ee architecture in olden days was
struts - action class - business delegate - session bean - jdbc/entity bean

DTO / Value object was required to covert from struts formbean to DTO and send it to business tier - persist and do the same thing in reverse.

But now in POJO programming model, the same entity/domain object can be used in UI tier and as well by the persistence framework (hibernate / kodo)

Using DTO in POJO programming model is an overhead / antipattern


You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>
Benoît de Chateauvieux
Ranch Hand

Joined: Aug 10, 2007
Posts: 183

At least with hibernate, the lazy loading collections implement the java.util interfaces, so even the POJOs don't need to know about them, let alone the presentation layer.


In order to test it, I have created an application deployed on a JBOSS.
The EAR expose a Stateless SB that returns a JPA entity with a lazy loaded collection.

The client is a pure J2SE that doesn't include the hibernate library in his classpath.

And when the JBoss client used by my test class try to unMarshall the JPA entity, I got the following in the log


Am I doing something wrong ?
Thanks a lot for your help,

Beno�t
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I was referring to the fact that the classes aren't referenced in the source code - they *do* need to be on the classpath, of course.

And it seems that you in fact *are* working with remote calls, which is exactly the reason for the existance of DTOs - although more for performance reaasons, as indicated by the article I linked to above.
Nachiket Patel
Ranch Hand

Joined: Sep 16, 2007
Posts: 110
Hello guys,
I never used POJO at presentation layer[client side], we used DTO. [Actually till date, i worked on single project only]

I am having query that, at j2se client, i received entity [POJO] say Department, which contains list of Employee entity [POJO]. So when i get department client side, actual employee list will not be there, but stub[proxy] will be there, and when i'll call getEmployee() or something on department, then employee list will be fetched?

Please correct my understanding, if i am wrong..

If my understanding is correct, then how employee's will be obtained?? Will client call directly to database?? [if yes, then client should be able to access database.]
[ December 04, 2008: Message edited by: Nachiket Patel ]

Before software can be reusable, it first has to be usable. - Ralph Johnson
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Nachiket Patel:

I am having query that, at j2se client, i received entity [POJO] say Department, which contains list of Employee entity [POJO]. So when i get department client side, actual employee list will not be there, but stub[proxy] will be there, and when i'll call getEmployee() or something on department, then employee list will be fetched?


Only if you are making use of the lazy loading feature of your ORM library.
J J Wright
Ranch Hand

Joined: Jul 02, 2008
Posts: 254
DTO also facilitates loose coupling between the presentation and business tiers, which is not to be sniffed at.

There's also the issue of lazy loading only being a 'hint' to the persistence provider. There's no guarantee your remote calls won't return a big object graph, which could be a problem.

Even though the POJO programming model in EE5 can make DTO feel like a waste of time there are still valid uses for it. The granularity of facade methods may also require aggregate DTOs - the POJO programming model doesn't invalidate the Transfer Object Assembler pattern.

I also don't think you you should be sending objects with lazily loaded associations to the client if you're planning on accessing the associated data. Once the object's detached, that's it - you can't access it.


SCJP, SCWCD, SCBCD, SCEA 5
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jonathan Aotearoa:
DTO also facilitates loose coupling between the presentation and business tiers, which is not to be sniffed at.


You don't need DTOs for that - simple Interface Segregation often already does the trick.
[ December 28, 2008: Message edited by: Ilja Preuss ]
J J Wright
Ranch Hand

Joined: Jul 02, 2008
Posts: 254
Are you suggesting that each POJO entity implements a presentation tier specific interface? I don't see how the Interface Segregation principle can be applied to POJO entities - they're just simple beans. And what happens if the presentation tier needs to modify an entity. The business tier will only see an object of type 'presentation tier interface' passed back to it, which the persistence provider won't know anything about.

The Interface Segregation principle also suggests that some properties won't be exposed to the presentation tier, in which case why incur unnecessary network overhead by sending them?

ORM provides only a limited degree of insulation from schema changes; if your entities change so does your presentation tier code. Admittedly, if you're data model is stable this might not be too big an issue.

Wouldn't a better principle be Dependency Inversion?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jonathan Aotearoa:

The Interface Segregation principle also suggests that some properties won't be exposed to the presentation tier, in which case why incur unnecessary network overhead by sending them?


Uh, if your presentation tier is remote, yes, please use DTOs. That wasn't obvious to me from your post...
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Domain Object Vs DTO....