aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes DTO/VO or a Universal Map 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 "DTO/VO or a Universal Map" Watch "DTO/VO or a Universal Map" New topic
Author

DTO/VO or a Universal Map

Ingudam Manoranjan
Ranch Hand

Joined: Jul 31, 2006
Posts: 48
For a web application which has the following layers


I need to transfer Objects across the layers to provide functionality. Right now, for each type of service, I have different Value Objects. Because of this the application layer or web layer, has much of the code doing Object copy

I am wandering if having a Universal Data carrier like a HashMap would be a valid option.
[ June 07, 2007: Message edited by: Ingudam Manoranjan ]
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
There are a lot of divided opinions on this issue.

My personal take on this is that I get faster development times, smaller and more understandable (and thus more maintainable) code by using such generic containers.

Others might disagree and point out that with specific classes you get code completion in your IDE and strong type checking of values.

All I can suggest is that you try both and see which suits your style.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Ingudam Manoranjan
Ranch Hand

Joined: Jul 31, 2006
Posts: 48
Thanks Frank.

Even within the design decision team over here, there is a lot of debate.

I agree with you on the lesser code and hence better manageability.


However, how do you unmarshal the HashMap in the Service layer? In your domain classes, do you have a constructor accepting the HashMap and build itself by getting the details from the HashMap.
[ June 08, 2007: Message edited by: Ingudam Manoranjan ]
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
I tend not to bother with domain classes if their only job is to hold data.

Typically I'll start with some use-case scenarios, and implement them by passing around some sort of "context" which provides access to named values as necessary. By starting my design from user needs, I resist the temptation to create a whole bunch of VOs or DTOs which are not really needed.

If, during this implementation I find a need for some domain-object-specific behaviour, then I'll consider creating a domain object to own that behaviour.

Does that make sense?
Ingudam Manoranjan
Ranch Hand

Joined: Jul 31, 2006
Posts: 48
Yes. It does. You mean incremental development and to avoid over design.

Thanks,
Mano
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Frank Carver:
I tend not to bother with domain classes if their only job is to hold data.

Typically I'll start with some use-case scenarios, and implement them by passing around some sort of "context" which provides access to named values as necessary. By starting my design from user needs, I resist the temptation to create a whole bunch of VOs or DTOs which are not really needed.

If, during this implementation I find a need for some domain-object-specific behaviour, then I'll consider creating a domain object to own that behaviour.

Does that make sense?


It feels to me like you are mixing two orthogonal topics here.

First, should a DTO be generic or specific? I don't have a strong opinion on this. Probably because I don't use DTOs very often.

Second, should you use a DTO or a domain object? In my opinion, using a DTO really only makes sense for distributed computing. If your layers are all running in the same JVM, I'd rather just pass domain objects around.

And I find that my domain objects, even if they might start as simple data holders, attract behaviour quite quickly. And they do that quicker if they are not designed as generic data holders, which I prefer for that reason.

Does *that* make sense?


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
Ingudam Manoranjan
Ranch Hand

Joined: Jul 31, 2006
Posts: 48
First, should a DTO be generic or specific? I don't have a strong opinion on this. Probably because I don't use DTOs very often.


Well basically there is a web layer which invokes service hosted in another server [ejb]. Hence the requirement for a DTO. However I have seen too much code going into populating the specifc DTO at the web layer and getting out the from the response DTO. Hence idea of having a generic DTO which is a universal container.

Service accepts the DTO, gives it domain [ in my case, thinking of having a constructor accepting the universal DTO]. Service use the Domain for any behavior related functionality.

And I find that my domain objects, even if they might start as simple data holders, attract behaviour quite quickly. And they do that quicker if they are not designed as generic data holders, which I prefer for that reason.


I completely agree. I think the intention should always be towards a proper domain.

Does *that* make sense?


Absolutely. :-)
Vinay Singh
Ranch Hand

Joined: Dec 15, 2004
Posts: 174
Ingudam
I have seen too much code being code just used to copy code from one class to another esp extracting values form request , setting them into VO/DTo and doing vice versa.
One practical solution which I have used and had to convince my team members is that keep the filed names in jsp excatly same as database field but in smaller cases . for eg if we have DOMAIN_ID in database use domain_id is jsp.
Now lets say we have created POJO with one is to one mapping of table names with the field name in small.
Now use apache's bean utils to transfer values from request to this POJO/DTO and same when want to display the data back to user.
This is single line of code which helps in transfer the values from one object to another.
I hope I have addressed the problem.


Technical quiz and interview questions   SCJP 6 mock practice test
Ingudam Manoranjan
Ranch Hand

Joined: Jul 31, 2006
Posts: 48
Thanks Vinay. I have been looking up at Expression Language of Jsp. And something that you said does strike to me and some feature is present in JSP EL as well. I will try to crystallize the idea in the next couple of days.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
In my experience, for all but the very simplest applications, it is not a good idea to directly reference database tables/fields in JSPs or other view code.

The reason is that the view and the database change for very different reasons. You probably don't want to have to take a look at, and possibly adjust, every single JSP when the name of a database column changes. Typically it's a rather good idea to totally decouple the view from the database.
Ingudam Manoranjan
Ranch Hand

Joined: Jul 31, 2006
Posts: 48
What you are telling is very valid Ilja Preuss. Maybe we can still go ahead with Vinay's suggestion to some extent.

What can happen is that we have the Bean generated from the Form and passed as DTO. In between, maybe an OR mapping will take care. That way, the table and object can still coexist independently.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: DTO/VO or a Universal Map
 
Similar Threads
how does Spring Roo help incorporate best practices
how many layers in jpetstore application ?
More about the domain objects in the domain layer
Value Objects in which layer
MVC example or tutorial