Sun Transfer Object Pattern renamed?
If you see the pattern here which Sun is calling TransferObject pattern
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
It seems as if that is a name change and the original name was ValueObject. All the pictures contain the name ValueObject. Furthermore the DAO pattern uses a TransferObject and not in the way implied by Sun's "TransferObject Pattern."
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
What gives?
[506 byte] By [
_dnoyeBa] at [2007-10-3 1:49:12]
Good explanation about the difference between Transfer Object (full name Date Transfer Object) and Value Object you find in Patterns of Enterprise Application Architecture by Martin Fowler.
Unambiguous descriptions of these J2EE patterns are here:
http://www.corej2eepatterns.com/Patterns2ndEd/DataAccessObject.htm
http://www.corej2eepatterns.com/Patterns2ndEd/TransferObject.htm
or here:
http://martinfowler.com/eaaCatalog/dataTransferObject.html
Yevhen
Martin Fowler and Eric Evans think of Value Objects as immutable classes, without identity, that anyone can share. One instance is as good as another, and there's no need to trace its identity in the application.
A good example of a Value Object is Money, which encapsulates a monetary value and its currency (e.g., $10 USD). There'd be no need to persist a Money instance on its own in a database. If I create a Money object that represents $10 USD, you can use it just as well as I can.
If I'm doing accounts payable, and I receive a Money object as part of a transaction, that instance is likely to be a child of a Transaction object. I persist it in the database, but the identity is carried by the Transaction itself.
DTO feels more like a Core Java EE anti-pattern these days than anything else.
%
> If you see the pattern here which Sun is calling
> TransferObject pattern
>
> http://java.sun.com/blueprints/corej2eepatterns/Patter
> ns/TransferObject.html
>
> It seems as if that is a name change and the original
> name was ValueObject.
Value Object was the original pattern. Over time it evolved functionally and with a name change to DTO.
> > DTO feels more like a Core Java EE anti-pattern these> days than anything else.To some people. Others do not consider it that way.
> >
> > DTO feels more like a Core Java EE anti-pattern
> these
> > days than anything else.
>
> To some people. Others do not consider it that way.
Agreed. Personal opinion. Here's my basis for it:
DTO has roots in EJB/J2EE where entity beans required a network roundtrip for each and every attribute, which was chatty and slow. Rather than pay that price, the pattern evolved so that the entity attributes were stuffed into a DTO, little more than a C struct, to make the state available to clients without the network overhead.
So now you'd have two parallel object trees, one for entity beans and another for DTOs, with identical attributes for each, all for the sake of avoiding that network traffic.
I think it's a bad design that came about to make up for deficiencies in the entity bean spec.
If you don't use entity beans, and stick with POJOs instead, there's no more reason for DTOs, because you don't have the network traffic. Now you can just pass the POJO around and let clients use it without the entity bean overhead.
What's your reason for liking it, Joe? I'd honestly like to hear why you think it's useful. My guess is that you want it to decouple layers. True? Other reasons that I'd be glad to know? Thanks.
%
I'm calling Sun on this one.
The usage and description of the TransferObject pattern here (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html) is definitely an anti-pattern. Passing ojects in and out of the business object is fine. But, objects returned by the business object should not be returned for purposes of avoiding calls on the business object. That is rediculous.
However, if you look at the "TransferObject" usage in Sun's DAO pattern (http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html), this is perfectly resonable. The DAO can return the transfer object for the business object to manipulate and store later. Or the business object can create its own object, modify it, then pass it to a method on the DAO along with an id, for storage. Thats normal relationship between business and DA objects.
The conflation of ValueObject with TransferObject looks like a political attempt to hide an anti-pattern behind a legitimate usage. There may be some similarities, but that does not make these the same objects.
ValueObject is an anti-pattern, TransferObject is not.
> > >
> > > DTO feels more like a Core Java EE anti-pattern these
> > > days than anything else.
> >
> > To some people. Others do not consider it that way.
>
> Agreed. Personal opinion. Here's my basis for it:
>
> DTO has roots in EJB/J2EE where entity beans required
> a network roundtrip for each and every attribute,
> which was chatty and slow.
I was using DTOs before J2EE existed.
J2EE is simply the place that you and probably others first encountered the pattern.
The pattern can be used in other places besides database interfaces as well.
> Rather than pay that
> price, the pattern evolved so that the entity
> attributes were stuffed into a DTO, little more than
> a C struct, to make the state available to clients
> without the network overhead.
>
> So now you'd have two parallel object trees, one for
> entity beans and another for DTOs, with identical
> attributes for each, all for the sake of avoiding
> that network traffic.
Although I believe I used an implementation like that once, all of the other times the attributes were not duplicated. The DTO became the sole source of the attributes.
>
> I think it's a bad design that came about to make up
> for deficiencies in the entity bean spec.
>
The entity bean spec itself is deficient for the vast majority of applications and perhaps for all. That has nothing to do with DTOs though.
And the DTO pattern can be used in other places.
> If you don't use entity beans, and stick with POJOs
> instead, there's no more reason for DTOs, because you
> don't have the network traffic. Now you can just
> pass the POJO around and let clients use it without
> the entity bean overhead.
Something is wrong with that statement.
In a client server architecture something must exist in the client that manages data. And something must exist on the server that provides the interface for that.
RMI for attribute values of course is not a viable solution. So some package of data must move between the client and the server.
>
> What's your reason for liking it, Joe? I'd honestly
> like to hear why you think it's useful. My guess is
> that you want it to decouple layers. True? Other
> reasons that I'd be glad to know? Thanks.
Could just be that I have been using it so long.
What specifically do you propose as an alternative?
Here is a code example for you to build upon.
class CustomerDto
{
public String name;
public String account;
}
class CustomerApi
{
CustomerDto GetFromSource();
void UpdateToSource(CustomerDto);
}
> I'm calling Sun on this one.
>
> The usage and description of the TransferObject
> pattern here
> (http://java.sun.com/blueprints/corej2eepatterns/Patte
> rns/TransferObject.html) is definitely an
> anti-pattern. Passing ojects in and out of the
> business object is fine. But, objects returned by
> the business object should not be returned for
> purposes of avoiding calls on the business object.
> That is rediculous.
>
> However, if you look at the "TransferObject" usage in
> Sun's DAO pattern
> (http://java.sun.com/blueprints/corej2eepatterns/Patte
> rns/DataAccessObject.html), this is perfectly
> resonable. The DAO can return the transfer object
> for the business object to manipulate and store
> later. Or the business object can create its own
> object, modify it, then pass it to a method on the
> DAO along with an id, for storage. Thats normal
> relationship between business and DA objects.
>
> The conflation of ValueObject with TransferObject
> looks like a political attempt to hide an
> anti-pattern behind a legitimate usage. There may be
> some similarities, but that does not make these the
> same objects.
>
> ValueObject is an anti-pattern, TransferObject is not.
That doesn't make ValueObject an anti-pattern even if true.
ValueObject is a pattern by itself. For it to be a anti-pattern the pattern itself must be flawed. Although one could make the argument that because it is used incorrectly so often versus when it is used correctly that would make it an antipattern (similar to arguments against Singleton.) But in that case you need to show that it actually being used incorrectly.
> That doesn't make ValueObject an anti-pattern even if
> true.
>
> ValueObject is a pattern by itself. For it to be a
> anti-pattern the pattern itself must be flawed.
> Although one could make the argument that because it
> is used incorrectly so often versus when it is used
> correctly that would make it an antipattern (similar
> to arguments against Singleton.) But in that case
> you need to show that it actually being used
> incorrectly.
I am trying to say that there is a fundamental difference in the way the so-called 'transfer object' is used in Sun's 'transfer object' pattern and the way it is used in Sun's 'DAO' pattern. Furthermore, that the usage in the rebranded 'Transfer Object' pattern makes the transfer object pattern as described by Sun an anti-pattern.
Furthermore, that Sun took liberties in even calling this object a TransferObject which is an affront to the usage of the object in the DAO pattern.
Its sowing confusion.
And I think Sun did this because they noticed their ValueObject pattern was an anti-pattern. It seems by your definition there are no anti-patterns only anti-usages?
> ValueObject is an anti-pattern, TransferObject is not.
Why is ValueObject an anti-pattern? No parallel hierarchy. No identity that has to be traced, according to the definition I gave. Thread-safe, usually immutable. Safely shareable.
Money might be one ValueObject; String would be another. Where's the anti-pattern?
%
> > What's your reason for liking it, Joe? I'd
> honestly
> > like to hear why you think it's useful. My guess
> is
> > that you want it to decouple layers. True? Other
> > reasons that I'd be glad to know? Thanks.
>
> Could just be that I have been using it so long.
Fair enough.
> What specifically do you propose as an alternative?
Use POJO domain objects and pass those around. No need for a Customer domain object and a CustomerDTO to pass between layers. Just pass Customer.
%
> > That doesn't make ValueObject an anti-pattern even
> if
> > true.
> >
> > ValueObject is a pattern by itself. For it to be
> a
> > anti-pattern the pattern itself must be flawed.
> > Although one could make the argument that because
> it
> > is used incorrectly so often versus when it is
> used
> > correctly that would make it an antipattern
> (similar
> > to arguments against Singleton.) But in that case
> > you need to show that it actually being used
> > incorrectly.
>
> I am trying to say that there is a fundamental
> difference in the way the so-called 'transfer object'
> is used in Sun's 'transfer object' pattern and the
> way it is used in Sun's 'DAO' pattern. Furthermore,
> that the usage in the rebranded 'Transfer Object'
> pattern makes the transfer object pattern as
> described by Sun an anti-pattern.
>
> Furthermore, that Sun took liberties in even calling
> this object a TransferObject which is an affront to
> the usage of the object in the DAO pattern.
>
> Its sowing confusion.
>
> And I think Sun did this because they noticed their
> ValueObject pattern was an anti-pattern. It seems by
> your definition there are no anti-patterns only
> anti-usages?
No.
I thought I made it quite clear.
The God pattern is an anti-pattern because by its very existance it contradicts the nature of OO programming. Thus the pattern is an anti-pattern.
Singleton has been considered an anti pattern because although it has observed proper usage there is some possibility that it is misused in many other ways.
Those are two separate ideas.
You stated explicitly that based on the what you saw in another pattern that it was misused. That means the other pattern is wrong. It doesn't mean that VO/DTO is wrong.
Conversely you have observed actual usage cases (patterns come about due to actual usage not hypothetical) where it was used incorrectly. This would be similar to the Singleton case.
> > > What's your reason for liking it, Joe? I'd
> > honestly
> > > like to hear why you think it's useful. My guess is
> > > that you want it to decouple layers. True? Other
> > reasons that I'd be glad to know? Thanks.
>
> Could just be that I have been using it so long.
>
> Fair enough.
>
> > What specifically do you propose as an
> alternative?
>
> Use POJO domain objects and pass those around. No
> need for a Customer domain object and a CustomerDTO
> to pass between layers. Just pass Customer.
>
How does that work in a client server architecture?
Not sure I understand the question, but that's never stopped me before. 8)
Client-server in this case would be a big Swing UI, with all the logic built into it, connecting directly to a relational database. Query the database, map the ResultSet into a POJO, hand that POJO to a Swing UI element to display.
Am I misunderstanding? Doesn't seem like a problem.
%
> You stated explicitly that based on the what you saw
> in another pattern that it was misused. That means
> the other pattern is wrong. It doesn't mean that
> VO/DTO is wrong.
>
Thats not what i said but I think I see your point.
Perhaps its better to call Sun's application/description of the ValueObject pattern a code smell as the way it is described on Suns page is a likely indication of other architectural problems.
But also remember that I am claiming that Sun should NOT have renamed this pattern to TransferObject pattern because it has nothing to do with the transfer object used by the DAO pattern. Its just confusing, and their own website still uses the term ValueObject in all their pics while they talk about TransferObject.
> Not sure I understand the question, but that's never
> stopped me before. 8)
>
> Client-server in this case would be a big Swing UI,
> with all the logic built into it, connecting directly
> to a relational database. Query the database, map
> the ResultSet into a POJO, hand that POJO to a Swing
> UI element to display.
So your client is going to directly connect to the database via the internet?
>
> Am I misunderstanding? Doesn't seem like a problem.
>
Having an open connection that is visible on the internet in a database would seem like a problem to me.
> > You stated explicitly that based on the what you saw
> > in another pattern that it was misused. That means
> > the other pattern is wrong. It doesn't mean that
> > VO/DTO is wrong.
> >
>
> Thats not what i said but I think I see your point.
>
> Perhaps its better to call Sun's
> application/description of the ValueObject pattern a
> code smell as the way it is described on Suns page is
> a likely indication of other architectural problems.
I know I found the blueprints overly complex. I haven't ever seen a case where all of that stuff could reasonably be used. Particularly given that the vast majority of software grows chaoticly (not that I am a fan of that but that is what I see.)
>
> But also remember that I am claiming that Sun should
> NOT have renamed this pattern to TransferObject
> pattern because it has nothing to do with the
> transfer object used by the DAO pattern. Its just
> confusing, and their own website still uses the term
> ValueObject in all their pics while they talk about
> TransferObject.
Not sure I see the point.
I do note that I never used the VO pattern. I never thought the immutability feature was wise. I use DTO like things all the time.
> So your client is going to directly connect to the
> database via the internet?
You're the one who said client/server, which means Intranet to me.
> Having an open connection that is visible on the
> internet in a database would seem like a problem to
> me.
Me too, but then that's not client/server as you requested.
%
From your post #13:
"How does that work in a client server architecture?"
I don't see where you said "client server over the Internet". Did I miss it?
Client/server is inherently an Intranet thing. The rise of the Internet is one of the reasons for the decline of client/server and the rise of 3- and n-tier architecture, IMO.
%
> From your post #13:
>
> "How does that work in a client server
> architecture?"
>
> I don't see where you said "client server over the
> Internet". Did I miss it?
Actually these days I always consider it that way. But I see your point.
>
> Client/server is inherently an Intranet thing. The
> rise of the Internet is one of the reasons for the
> decline of client/server and the rise of 3- and
> n-tier architecture, IMO.
So then making it explicitly over the internet then - are your clients going to be using POJO?
If not then how are you going to move the data over the internet?
Not client/server if it's over the Internet. I'll always have at least three tiers. I'll have a servlet that's listening for requests, handling security, routing requests, etc.
POJOs will be given to JSPs that will be used to generate HTML that's presented in the browser. So POJOs stay on the server side.
When the client has another request, the HTTP GET or POST goes to the front controller servlet. The FCS binds parameters, routes to services, gets the response and next view, and redirects to the next JSP.
%
> Not client/server if it's over the Internet. I'll
> always have at least three tiers. I'll have a
> servlet that's listening for requests, handling
> security, routing requests, etc.
>
> POJOs will be given to JSPs that will be used to
> generate HTML that's presented in the browser. So
> POJOs stay on the server side.
>
> When the client has another request, the HTTP GET or
> POST goes to the front controller servlet. The FCS
> binds parameters, routes to services, gets the
> response and next view, and redirects to the next
> JSP.
The data moves to the browser.
Presuming that the browser is using an applet rather than html how are you going to move the data to the applet?
> The data moves to the browser.
>
> Presuming that the browser is using an applet rather
> than html how are you going to move the data to the
> applet?
I never write applets. 8) I'm ignorant.
Applets are making HTTP requests to the server. How are data elements bound in an applet? I think I know what happens with an HTML form: name, value pairs bound as parameters to the HTTP request.
If I had an applet with JTextFields in it, how would those values be sent to the server? It's been so long since I last thought about applets that I'm embarrassed to admit that I don't know.
Are they passed by reference? 8) Or is it pointer-to-reference-to-pointer voodoo magic? Maybe I'll ask DaFei...it's obvious that YOU don't know anything about Java references.
%
> > The data moves to the browser.
> >
> > Presuming that the browser is using an applet
> rather
> > than html how are you going to move the data to
> the
> > applet?
>
> I never write applets. 8) I'm ignorant.
>
> Applets are making HTTP requests to the server. How
> are data elements bound in an applet? I think I know
> what happens with an HTML form: name, value pairs
> bound as parameters to the HTTP request.
>
> If I had an applet with JTextFields in it, how would
> those values be sent to the server? It's been so
> long since I last thought about applets that I'm
> embarrassed to admit that I don't know.
>
> Are they passed by reference? 8) Or is it
> pointer-to-reference-to-pointer voodoo magic? Maybe
> I'll ask DaFei...it's obvious that YOU don't know
> anything about Java references.
>
Couldn't say.
All I know is that I was passing DTOs to the GUI people and they were using those to populate screens and allow user input (by returning them to the back end.)
I certainly couldn't have passed POJOs to them. I certainly would not have wanted to pass individual attributes.
> Couldn't say.
Just kidding of course.
> All I know is that I was passing DTOs to the GUI
> people and they were using those to populate screens
> and allow user input (by returning them to the back
> end.)
>
> I certainly couldn't have passed POJOs to them.
Hold on - what are you saying is the feature that distinguishes a POJO from a DTO? Are they not Java objects that follow the Java Bean conventions?
The POJO acronym came about to distinguish Plain Old Java Beans from Enterprise Java Beans. So why do you say that a DTO is not a POJO?
%
> I certainly would not have wanted to pass individual
> attributes.
Obviously - they've gotta belong to some object, and one object per attribute would be a bit granular; no, gritty. (Seems more distasteful with that word, something to be avoided.)
%
> > Couldn't say.
>
> Just kidding of course.
I wasn't. I only have the vague idea what goes on in GUIs.
>
> > All I know is that I was passing DTOs to the GUI
> > people and they were using those to populate screens
> > and allow user input (by returning them to the back
> > end.)
> >
> > I certainly couldn't have passed POJOs to them.
>
> Hold on - what are you saying is the feature that
> distinguishes a POJO from a DTO? Are they not Java
> objects that follow the Java Bean conventions?
They? POJO? DTO?
And even so what does that have to do with how the data is transported?
>
> The POJO acronym came about to distinguish Plain Old
> Java Beans from Enterprise Java Beans. So why do you
> say that a DTO is not a POJO?
>
POJO so far as I know and in terms of this discussion has functionality and is a full fleged object.
A DTO doesn't. It is minimally just a collection of attributes.
> %
>
>
> > I certainly would not have wanted to pass individual
> > attributes.
>
> Obviously - they've gotta belong to some object, and
> one object per attribute would be a bit granular; no,
> gritty. (Seems more distasteful with that word,
> something to be avoided.)
Yes.And that would be my point. That object that one passes is a DTO.
> The God pattern is an anti-pattern because by its
> very existance it contradicts the nature of OO
> programming. Thus the pattern is an anti-pattern.
>
> Singleton has been considered an anti pattern because
> although it has observed proper usage there is some
> possibility that it is misused in many other ways.
>
> Those are two separate ideas.
Not really.
The generally accepted idea of what constitutes an antipattern is that of a recurring bad solution to a given problem, and makes no reference to OO.
One case where the God Class could be acceptable would be when wrapping a legacy system. In that case, the refactoring of the class is not needed. Another case would be when coding a throw-away prototype. The partitioning the class in an MVC fashion (for example) would be counter-productive.
So the God Class has proper usage too. So have most of listed antipatterns, in a section usually called "Known Exceptions".
And the reason why Singleton is often considered an antipattern is the same as that of God Class, and most other antipatterns.
> > The God pattern is an anti-pattern because by its
> > very existance it contradicts the nature of OO
> > programming. Thus the pattern is an anti-pattern.
> >
> > Singleton has been considered an anti pattern
> because
> > although it has observed proper usage there is
> some
> > possibility that it is misused in many other ways.
> >
> > Those are two separate ideas.
>
>
> Not really.
>
> The generally accepted idea of what constitutes an
> antipattern is that of a recurring bad solution to
> a given problem, and makes no reference to OO.
>
Errr...perhaps you missed the long thread where I suggested that patterns could be applied to things besides OO and others insisted that patterns could only exist in OO? ;)
> One case where the God Class could be acceptable
> would be when wrapping a legacy system. In that case,
> the refactoring of the class is not needed. Another
> case would be when coding a throw-away prototype. The
> partitioning the class in an MVC fashion (for
> example) would be counter-productive.
>
> So the God Class has proper usage too. So have most
> of listed antipatterns, in a section usually called
> "Known Exceptions".
>
I have only ever seen the god pattern listed as an anti-pattern. I don't recall a known exceptions section(s) at all for that particular book.
> And the reason why Singleton is often considered an
> antipattern is the same as that of God Class, and
> most other antipatterns.
As I recall the reasons were different.
So its accepted that POJO stands for more than plain old java object, but that it stands for Java Bean?
> > The generally accepted idea of what constitutes an
> > antipattern is that of a recurring bad solution
> to
> > a given problem, and makes no reference to
> OO.
> >
>
> Errr...perhaps you missed the long thread where I
> suggested that patterns could be applied to things
> besides OO and others insisted that patterns could
> only exist in OO? ;)
I must have misssed that.
As for antipatterns, their general definition do not even make reference to programming either, as there are antipatterns in Project Management too.
>
> So the God Class has proper usage too. So have most
> of listed antipatterns, in a section usually called
>"Known Exceptions".
>
>
> I have only ever seen the god pattern listed as an
> anti-pattern. I don't recall a known exceptions
> section(s) at all for that particular book.
I wasn't refering to any particular book. But come to think of it , the one called AntiPatterns - Refactoring Software, Architectures, and Projects in Crisis
has a known exceptions section for rmost of them.
> So its accepted that POJO stands for more than plain
> old java object, but that it stands for Java Bean?
By whom?
I suppose it's true that POJOs are a subset of Java Beans. It'd be important to review what constitutes a Java Bean:
http://java.sun.com/developer/onlineTraining/Beans/beans02/
(1) Implements java.io.Serializable
(2) Property access follows Java Bean standards (X getX() for read access to non-boolean properties, isX() or hasX() for boolean properties, void setX(X x) for write access to properties)
If you write a POJO that follows the get/set conventions but does not implement Serializable, then it's not a Java Bean.
%
> I never write applets. 8) I'm ignorant.
>
> Applets are making HTTP requests to the server. How
> are data elements bound in an applet? I think I know
> what happens with an HTML form: name, value pairs
> bound as parameters to the HTTP request.
>
> If I had an applet with JTextFields in it, how would
> those values be sent to the server? It's been so
> long since I last thought about applets that I'm
> embarrassed to admit that I don't know.
My understanding is that it would be done the same way that a non-applet fat client does it. In other words, you have to figure out how you will talk to the server and do it. It's not automagical.
I looked through the Applet tutorial to verify and it seems to confirm what I had thought.
> > So its accepted that POJO stands for more than
> plain
> > old java object, but that it stands for Java Bean?
>
> By whom?
>
By the way you were using the term I got the impression you were trying to juxtapose POJO against an EJB. And thus your value in the term was realted to its beanness.
> By the way you were using the term I got the
> impression you were trying to juxtapose POJO against
> an EJB. And thus your value in the term was realted
> to its beanness.
Nobody ever mentioned EJB. I have no idea where you got that. Java Beans are very different animals from EJBs.
%
You said> The POJO acronym came about to distinguish Plain Old> Java Beans from Enterprise Java Beans. So why do you> say that a DTO is not a POJO?>
OK, I see your point. Still not sure what you're getting at.
The term didn't come about to judge the "beanness" of POJOs or EJBs. It's because in Java "Bean" is overloaded, and some people were confusing Java Beans, which do not require a container to run and are most certainly not Enterprise Java Beans. It doesn't make one less of a "bean" than the other.
%
