DTO == VO
[162 byte] By [cybotx] at [2007-9-30 13:39:52] 
Is a Data Transfer Object == Value Object ?ORDoes a DTO contain many Value Objects ? Thanks in advance for the responses.
My understanding is that the DTO replaces the VO pattern. Basically, people weren't getting the point of the pattern so they renamed it in order to clarify it's purpose.
dubwai at 2007-7-4 22:35:04 >
IIRC ValueObject was already in (maybe colloquial?) use when Sun put it in the J2EE patterns catalog, so to avoid confusion they changed the name to DTO (a term which, again if memory serves, Martin Fowler coined way back in the day)
tsith at 2007-7-4 22:35:04 >
[url=http://www.martinfowler.com/eaaCatalog/dataTransferObject.html]Here's Fowler on this topic[/url].
This is the reason that Core J2EE Patterns uses the term Transfer Object for this pattern. The other difference in the Transfer Object is that fields are now defined as public and the getters and setters are gone.
pkwooster at 2007-7-4 22:35:04 >
> [url=http://www.martinfowler.com/eaaCatalog/dataTransfe
> Object.html]Here's Fowler on this topic[/url].
>
> This is the reason that Core J2EE Patterns uses the
> term Transfer Object for this pattern. The other
> difference in the Transfer Object is that fields are
> now defined as public and the getters and setters are
> gone.
No. They are optional. In the VO they were required.
The VO also mandated non-mutable classes. DTOs are mutable (actually I would have thought that this would be optional as well but the pattern claims it must be.)
jschell at 2007-7-4 22:35:04 >
Here is the DTO link... http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.htmlAnd VO... http://developer.java.sun.com/developer/restricted/patterns/ValueObject.html
jschell at 2007-7-4 22:35:04 >
> >
> [url=http://www.martinfowler.com/eaaCatalog/dataTransfe
> > Object.html]Here's Fowler on this topic[/url].
> >
> > This is the reason that Core J2EE Patterns uses the
> > term Transfer Object for this pattern. The other
> > difference in the Transfer Object is that fields are
> > now defined as public and the getters and setters
> are
> > gone.
>
> No. They are optional. In the VO they were required.
>
> The VO also mandated non-mutable classes. DTOs are
> mutable (actually I would have thought that this would
> be optional as well but the pattern claims it must
> be.)
>
i do not see any difference in between DTOs and VOs, they are EXACTLY the same, they are simple half objects, just a little better than C structures in that DTOs or VOs can optionally make members non public and provide controls in setters and getters.
jschell at 2007-7-4 22:35:04 >
> Is a Data Transfer Object == Value Object ?yes. > Does a DTO contain many Value Objects ?> you can do whatever you want to but keep in mind, there is no point to complicate things here, as they are meant to simplyfy things.
jschell at 2007-7-4 22:35:04 >
> Here is the DTO link...
>
> http://java.sun.com/blueprints/corej2eepatterns/Pattern
> /TransferObject.html
>
> And VO...
>
> http://developer.java.sun.com/developer/restricted/patt
> rns/ValueObject.html
Jschell, maybe you can straighten this out.
The diagrams and examples in the online version of the core J2EE Patterns vary considerably from those in the book by Alur, Crupi and Malks.
In the book the pattern is called Transfer Object, not DTO or VO. The diagrams are consistent.
In the online corej2eepatterns the TransferObject still refers to ValueObjects in the diagrams.
Is the online version out of date? I notice that it is copyright 2002 and the book is 2003.
BTW, the book agrees with you that:
"Choosing whether to make the TransferObject's attributes private and accessed by getter and setter methods, or public, is a design choice you make based on application requirements".
pkwooster at 2007-7-4 22:35:04 >
improve your reading skills! all those places are telling you they are one thing with two, or more, names.
pkwooster at 2007-7-4 22:35:04 >
vos, tos, dtos... they are like structures, meant to be used to transfer a set of data at once, for the purpose of reducing network tracfic. it is a design pattern, there is NO defition of it, you can do the way you see as fit, implement serilizable interface is the only requirement. if you feel somehow you have read somewhere any defenitions of it, you are delusioned.
pkwooster at 2007-7-4 22:35:04 >
> The VO also mandated non-mutable classes. DTOs are
> mutable (actually I would have thought that this would
> be optional as well but the pattern claims it must
> be.)
The TransferObject in the AC&M coreJ2EE Patterns book states "To protect an immutable TransferObject from modification after its creation, don't provide setter methods." So it appears that they allow for optional immutability.
pkwooster at 2007-7-4 22:35:04 >
> > The VO also mandated non-mutable classes. DTOs are
> > mutable (actually I would have thought that this
> would
> > be optional as well but the pattern claims it must
> > be.)
>
> The TransferObject in the AC&M coreJ2EE Patterns book
> states "To protect an immutable TransferObject from
> modification after its creation, don't provide setter
> methods." So it appears that they allow for optional
> immutability.
>
you are right, joe was wrong on this; but the funny thing is joe himself sometime ago said vo = dto.
pkwooster at 2007-7-4 22:35:04 >
>
> Is the online version out of date? I notice that it
> is copyright 2002 and the book is 2003.
That would suggest that at some point that they were "in date".
Compared to the GoF the J2EE patterns do not seem as rigorous to me. But then I don't really consider that patterns need rigorous definitions.
jschell at 2007-7-4 22:35:04 >
>
> i do not see any difference in between DTOs and VOs,
> they are EXACTLY the same,
Wrong.
> they are simple half
> objects, just a little better than C structures in
> that DTOs or VOs can optionally make members non
> public and provide controls in setters and getters.
And of course nothing in what you said above contradicts the intent of DTOs. The overall strategy is the important part, not the specifics of the suggested implementations.
jschell at 2007-7-4 22:35:04 >
> vos, tos, dtos... they are like structures, meant to
> be used to transfer a set of data at once, for the
> purpose of reducing network tracfic. it is a design
> pattern, there is NO defition of it, you can do the
> way you see as fit, implement serilizable interface is
> the only requirement.
That isn't entirely correct. First DTOs are useful in ways that have nothing to do with network traffic. The first time I used them they didn't travel on the network. And in the second case network traffic was not considered.
> if you feel somehow you have
> read somewhere any defenitions of it, you are
> delusioned.
And so you are saying that the links that I provided do not work? Or that they exist merely as some mass conspiracy by some quasi-governmental organization whose sole goal is to prosecute you?
jschell at 2007-7-4 22:35:06 >
> > vos, tos, dtos... they are like structures, meant to
> > be used to transfer a set of data at once, for the
> > purpose of reducing network tracfic. it is a design
> > pattern, there is NO defition of it, you can do the
> > way you see as fit, implement serilizable interface
> > is the only requirement.
>
> That isn't entirely correct. First DTOs are useful in
> ways that have nothing to do with network traffic.
they are useful in between layers among servers and clients; otherwise they are really not that useful to have them.
> The first time I used them they didn't travel on the
> network. And in the second case network traffic was
> not considered.
i have seen lots of people with vb background use them all the time as they can not write proper classes, and they feel better as dtos allow them to carray bounched vars at once, better than vb of course.
> > if you feel somehow you have
> > read somewhere any defenitions of it, you are
> > delusioned.
>
> And so you are saying that the links that I provided
> do not work?
i guess you never read the links yourself, they are saying dot=vo. here i am pasting them here:
TransferObject
The TransferObject is an arbitrary serializable Java object referred to as a Transfer Object. A Transfer Object class may provide a constructor that accepts all the required attributes to create the Transfer Object. The constructor may accept all entity bean attribute values that the Transfer Object is designed to hold. Typically, the members in the Transfer Object are defined as public, thus eliminating the need for get and set methods. If some protection is necessary, then the members could be defined as protected or private, and methods are provided to get the values. By offering no methods to set the values, a Transfer Object is protected from modification after its creation. If only a few members are allowed to be modified to facilitate updates, then methods to set the values can be provided. Thus, the Transfer Object creation varies depending on an application's requirements. It is a design choice as to whether the Transfer Object's attributes are private and accessed via getters and setters, or all the attributes are made public.
ValueObject
The ValueObject is an arbitrary Java object. The ValueObject may provide a constructor that accepts all the required attributes to create the value object. The constructor may accept all entity bean attribute values that the value object is designed to hold. Typically, the members in the ValueObject are defined as public, thus eliminating the need for get and set methods. If some protection is necessary, then the members could be defined as protected or private, and methods to get are provided to get the values. By offering no methods to set the values, a ValueObject is protected from modification after its creation. If only a few members are allowed to be modified to facilitate updates, then methods to set the values can be provided. Thus, the Value object creation varies depending on an application's requirements. It is a design choice as to whether the ValueObject attributes are private and accessed via getters and setters, or all the attributes are made public.
>Or that they exist merely as some mass
> conspiracy by some quasi-governmental organization
> whose sole goal is to prosecute you?
>
i view dtos, vos as a step backword: seperating data and functions, and i am troubled, even i understand it is just a design pattern. using interfaces for data transfers among layers or client servers is better.
jschell at 2007-7-4 22:35:06 >
Watching daFei argue with jschell is like watching my 3-year-old on his tricycle race against Lance Armstrong.
jverd at 2007-7-4 22:35:06 >
> >
> > Is the online version out of date? I notice that it
> > is copyright 2002 and the book is 2003.
>
> That would suggest that at some point that they were
> "in date".
>
> Compared to the GoF the J2EE patterns do not seem as
> rigorous to me. But then I don't really consider that
> patterns need rigorous definitions.
Thanks, that's the impression I was getting, that the J2EE patterns aren't as rigorous and possibly still undergoing refinement.
pkwooster at 2007-7-4 22:35:06 >
> i guess you never read the links yourself, they are
> saying dot=vo. here i am pasting them here:
The problem with ValueObject as a synonym for DataTransferObject is that the term was already in use for a very different concept. See http://www.martinfowler.com/bliki/ValueObject.html for an explanation. This link http://www.riehle.org/computer-science/research/1998/ubilab-tr-1998-10-1.html provides more details.
Classes like Integer and String fit Fowler's ValueObject description of a simple immutable object whose equality is not based on identity.
pkwooster at 2007-7-4 22:35:06 >
> Classes like Integer and String fit Fowler's
> ValueObject description of a simple immutable object
> whose equality is not based on identity.
>
in their term, vo should be like the string, integer, and they complained that "Date, Point, and Rectangle" were not. but they should have realized the values in the object are actually immutable already. the impression i got from reading that 1998 report was that they really wanted to go separating values and functions. and they seemed to be more interested in arguing oo aproaches rather then the applications of vos, or dtos. the context seems to be different. if you look at sun's docs on vos and dtos, links as provided by jschell, the first line is the context: "Application clients need to exchange data with enterprise beans."
pkwooster at 2007-7-4 22:35:06 >
i think there is some sort of implementation called jvalue.jar...
pkwooster at 2007-7-4 22:35:06 >
> > > vos, tos, dtos... they are like structures, meant to
> > > be used to transfer a set of data at once, for the
> > > purpose of reducing network tracfic. it is a design
> > > pattern, there is NO defition of it, you can do the
> > > way you see as fit, implement serilizable interface
> > > is the only requirement.
> >
> > That isn't entirely correct. First DTOs are useful in
> > ways that have nothing to do with network traffic.
>
> they are useful in between layers among servers and
> clients; otherwise they are really not that useful to
> have them.
Which is exactly what you said before.
And as I said that isn't correct.
You can use DTOs in an application that does not do network traffic (at least not via DTOs.)
>
> > The first time I used them they didn't travel on the
> > network. And in the second case network traffic was
> > not considered.
>
> i have seen lots of people with vb background use them
> all the time as they can not write proper classes, and
> they feel better as dtos allow them to carray bounched
> vars at once, better than vb of course.
>
You a denigrating the grouping as though that was a bad thing. Certainly they could be using them incorrectly but that doesn't alter the fact that larger applications often have related data that can be grouped.
> > > if you feel somehow you have
> > > read somewhere any defenitions of it, you are
> > > delusioned.
> >
> > And so you are saying that the links that I provided
> > do not work?
>
> i guess you never read the links yourself, they are
> saying dot=vo. here i am pasting them here:
>
> TransferObject
> The TransferObject is an arbitrary serializable Java
> object referred to as a Transfer Object. A Transfer
> Object class may provide a constructor that accepts
> all the required attributes to create the Transfer
> Object. The constructor may accept all entity bean
> attribute values that the Transfer Object is designed
> to hold. Typically, the members in the Transfer Object
> are defined as public, thus eliminating the need for
> get and set methods. If some protection is necessary,
> then the members could be defined as protected or
> private, and methods are provided to get the values.
> By offering no methods to set the values, a Transfer
> Object is protected from modification after its
> creation. If only a few members are allowed to be
> modified to facilitate updates, then methods to set
> the values can be provided. Thus, the Transfer Object
> creation varies depending on an application's
> requirements. It is a design choice as to whether the
> Transfer Object's attributes are private and accessed
> via getters and setters, or all the attributes are
> made public.
>
> ValueObject
> The ValueObject is an arbitrary Java object. The
> ValueObject may provide a constructor that accepts all
> the required attributes to create the value object.
> The constructor may accept all entity bean attribute
> values that the value object is designed to hold.
> Typically, the members in the ValueObject are defined
> as public, thus eliminating the need for get and set
> methods. If some protection is necessary, then the
> members could be defined as protected or private, and
> methods to get are provided to get the values. By
> offering no methods to set the values, a ValueObject
> is protected from modification after its creation. If
> only a few members are allowed to be modified to
> facilitate updates, then methods to set the values can
> be provided. Thus, the Value object creation varies
> depending on an application's requirements. It is a
> design choice as to whether the ValueObject attributes
> are private and accessed via getters and setters, or
> all the attributes are made public.
>
And you are claiming that the above is exactly the same?
Just the fact that the attributes in one can be public and that is specifically forbidden in the other makes them different.
>
> >Or that they exist merely as some mass
> > conspiracy by some quasi-governmental organization
> > whose sole goal is to prosecute you?
> >
> i view dtos, vos as a step backword: seperating data
> and functions, and i am troubled, even i understand it
> is just a design pattern. using interfaces for data
> transfers among layers or client servers is better.
>
I can't help you with that problem. Perhaps with more experience you will begin to understand that data moves between layers whereas functionality that is useful in one layer should never exist in a different layer.
jschell at 2007-7-4 22:35:06 >
> > >
> > > Is the online version out of date? I notice that it
> > > is copyright 2002 and the book is 2003.
> >
> > That would suggest that at some point that they were
> > "in date".
> >
> > Compared to the GoF the J2EE patterns do not seem as
> > rigorous to me. But then I don't really consider that
> > patterns need rigorous definitions.
>
>
> Thanks, that's the impression I was getting, that the
> J2EE patterns aren't as rigorous and possibly still
> undergoing refinement.
I already stated the first. As to whether they will achieve the second I am not going to be holding my breath.
jschell at 2007-7-4 22:35:06 >
> > i guess you never read the links yourself, they are
> > saying dot=vo. here i am pasting them here:
>
> The problem with ValueObject as a synonym for
> DataTransferObject is that the term was already in use
> for a very different concept. See
> http://www.martinfowler.com/bliki/ValueObject.html for
> an explanation. This link
> http://www.riehle.org/computer-science/research/1998/ub
> lab-tr-1998-10-1.html provides more details.
>
> Classes like Integer and String fit Fowler's
> ValueObject description of a simple immutable object
> whose equality is not based on identity.
Interesting. (Not sure I agree with the immutable part though.)
jschell at 2007-7-4 22:35:06 >
> Watching daFei argue with jschell is like watching my> 3-year-old on his tricycle race against Lance> Armstrong.At least he appears to be getting better. Some of the early posts were literally incoherent.
jschell at 2007-7-4 22:35:06 >
> > TransferObject
> >Typically, the members in the Transfer
> >Object are defined as public...
> > If some protection is necessary,
> > then the members could be defined as protected or
> > private, and methods are provided to get the values.
> > By offering no methods to set the values,
> > ValueObject
> > Typically, the members in the ValueObject are
> >defined as public, thus eliminating the need for get and set
> > methods. If some protection is necessary, then the
> > members could be defined as protected or private,
> > and methods to get are provided to get the values. By
> > offering no methods to set the values,
> And you are claiming that the above is exactly the
> same?
>
and you think they are not?
> Just the fact that the attributes in one can be public
> and that is specifically forbidden in the other makes
> them different.
>
WHERE is it?
> > >Or that they exist merely as some mass
> > > conspiracy by some quasi-governmental organization
> > > whose sole goal is to prosecute you?
> > >
you must be a member of them
jschell at 2007-7-4 22:35:06 >
>
> > Just the fact that the attributes in one can be public
> > and that is specifically forbidden in the other
> makes
> > them different.
> >
> WHERE is it?
Sorry I didn't actually read it.
I am rather certain that the original version did claim that they should be immutable.
Here is a link that demonstrates the same argument (if I remember) that the original one claimed for the reason they should be immutable....
http://www.two-sdg.demon.co.uk/curbralan/papers/javaspektrum/UnfinishedSymmetry.pdf
(As the name alias search does not work I can not currently find any original links to the pattern.)
jschell at 2007-7-4 22:35:06 >
Ok, it's year 2006 now but I still have this doubt. I see that the link to the "value object" pattern is gone, so I guess this is the right answer:
> My understanding is that the DTO replaces the VO
> pattern. Basically, people weren't getting the point
> of the pattern so they renamed it in order to clarify
> it's purpose.
Am I right?
PD: I hope there isn't any rule prohibiting to revive old threads!
Shandrio at 2007-7-4 22:35:06 >
Hi
As per my understanding,
DTO - Object is initialized one during construction and have only getter methods. It is used just to carry data from one place to another (e.g. Entity beans response)
VO - Empty or partially filled object is initialized at start and then as application processes, VO object modifies. It has setter and getter methods for almost all attributes.
Regards,
Milind Patil
milind_b_patil at 2007-7-4 22:35:06 >
Other Topics New Topic
Other Topics Hot Topic
Other Topics
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding