Domain Object Vs DTO....

[Senthil Narayanaswamy]

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]

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]

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 ]

[Benoît de Chateauvieux]

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

[Ilja Preuss]

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]

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

[Benoît de Chateauvieux]

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

java.lang.NoClassDefFoundError: Lorg/hibernate/type/AbstractComponentType;
...
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:133)

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

Beno�t

[Ilja Preuss]

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]

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 ]

[Ilja Preuss]

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]

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.

[Ilja Preuss]

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]

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]

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...