Can I use Business Objects (BOs) as Transfer Objects (TOs)

[Gundum Hoi]

For reasonably simple system/webapp, can I use Business Objects (BOs) as Transfer Objects (TOs). What I mean here is, instead of having UserBO (properties + biz methods) and UserTO (properties + getters/setters), I do away with all TOs...and just use BOs to transfer data across tiers. Is there any major issue/problem with this ?

Note that my system is a fairly simple webapp. I just don't see the need to have "redundant" classes like
- StudentBO and StudentTO
- AdminBO and AdminTO etc

Thanks.

[Ilja Preuss]

You are right on:

from http://www.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.

Couldn't say it better.

[Darya Akbari]

Hi gundum hoi,

I would say that it depends on the underlaying framework you use. If it is J2EE's EJB 2 technology and whether your Business Objects (BO) are remote objects or not.

If your BOs are not remote objects you can not use them as TO of course. But lets assume you want to use J2EE's Entity Beans as BO then you could do so but you should keep in mind that EJB 2's entity beans cannot be efficiently accessed by the presentation tier and dramatically slow down your application.

Regards,
Darya

[Kishore Dandu]

Simple is different from the load on the system. If the system you are hosting as web-app is accessed extensively; i would have both business objects & the lean version of them for remote transfer purposes to save some bandwidth for other needs.

[Stan James]

DTOs might make sense when the client and service consider themselves well separated components.

Pretend for a moment the client is another system and their developers have asked to call one of your services. If your service returns a simple JavaBean DTO they can pull the data out and go merrily on their way. If your service returns a rich business object it may have dependencies on other business objects, helpers, etc. It may have functionality that won't work over in the other system.

Now the client is not another system being developed by strangers, but your own component. Even so, take a moment to see if the client component is getting more than it needs or can use.

I dislike the whole DTO and Anemic Model style architecture, so I hope the BOs will work for you!

[Ilja Preuss]

Originally posted by Kishore Dandu:
Simple is different from the load on the system. If the system you are hosting as web-app is accessed extensively; i would have both business objects & the lean version of them for remote transfer purposes to save some bandwidth for other needs.

You are assuming some remote communication inside the system here, aren't you?

[Ilja Preuss]

Originally posted by Darya Akbari:

I would say that it depends on the underlaying framework you use. If it is J2EE's EJB 2 technology and whether your Business Objects (BO) are remote objects or not.

Well, I wouldn't call anything that uses EJBs or remote objects "simple"...

[Mr. C Lamont Gilbert]

I disagree. TO shows a clear seperation of behavior from a BO. I can't see anyreason to conflate these two.

I find it hard to believe the data that is transferred in the DTO is the same data and form that would be transferred in and out of a BO.

If I conflated these two it would force me to expose the internal state of my BO in a format conducive to persistence. Currently my BOs don't care about persistence.

[Darya Akbari]

Originally posted by Ilja Preuss:


Well, I wouldn't call anything that uses EJBs or remote objects "simple"...

It always depends for whom something is simple . On the other hand, since he talks about TO and BO I think he has already entered the J2EE arena including EJB.

Regards,
Darya

[Ilja Preuss]

Originally posted by Darya Akbari:
It always depends for whom something is simple .

Well, perhaps. I can't imagine a situation where I would call EJBs "simple", though... :roll:

On the other hand, since he talks about TO and BO I think he has already entered the J2EE arena including EJB.

I'm not sure how you come to that conclusion. Almost every system has BOs, and TOs could well be used with simple RMI or something...

[Ilja Preuss]

Originally posted by Mr. C Lamont Gilbert:
I disagree. TO shows a clear seperation of behavior from a BO. I can't see anyreason to conflate these two.

Well, as TOs don't have any behaviour at all, I don't see what would get conflated.

As the article that I quoted above states, TOs were invented to improve performance of remote calls.

I find it hard to believe the data that is transferred in the DTO is the same data and form that would be transferred in and out of a BO.

I'm not sure I'm following you. Could you give a concrete example of what bad could happen if you used a BO in a place of a DTO?

If I conflated these two it would force me to expose the internal state of my BO in a format conducive to persistence. Currently my BOs don't care about persistence.

I agree that BOs shouldn't care about persistence. I'm not sure that without DTOs they have to.

[Ilja Preuss]

Originally posted by Stan James:
Now the client is not another system being developed by strangers, but your own component. Even so, take a moment to see if the client component is getting more than it needs or can use.

If I hit such a problem, I'd prefer to try smaller granular BOs first...

[Mr. C Lamont Gilbert]

I won't give a concrete example of what bad could happen. Thats like asking to give an example of what bad happens if you violate OO principles.

My point about BO and TO is that I see this conflation recommended mostly by people whose BOs only have getters and setters like their TOs. They don't consider us folk whose BOs actually perform some type of work on the data before they expose it. Therefore, my BOs expose data in a format that would not be saveable by any DAO. If I were forced to conflate them I would have to alter the way my BOs expose data.

[Darya Akbari]

I said, I think he has entered the J2EE arena. Of course I only guess. As long as gundum hoi does not share more light on his design there is no more I can do .

Originally posted by Ilja Preuss:

I'm not sure how you come to that conclusion. Almost every system has BOs, and TOs could well be used with simple RMI or something...

It's the wording he uses to describe Business Object (BO) and Transfer Object (TO) why I guess :roll: that he already entered the J2EE arena. Both BO and TO belong into J2EE's terminology.

Regards,
Darya

[Ilja Preuss]

Originally posted by Darya Akbari:
I said, I think he has entered the J2EE arena.

Well, I'm rather sure he has - he already has if he has written a single Servlet.

You don't need to use EJBs to be using J2EE. (I'd go even farther and say that most J2EE apps actually *shouldn't* use EJBs, but that's a different topic...)

It's the wording he uses to describe Business Object (BO) and Transfer Object (TO) why I guess :roll: that he already entered the J2EE arena. Both BO and TO belong into J2EE's terminology.

Uh, no, not at all. Both the terms BO and TO (or in fact *Data Transfer Object*, which is the actual name of the pattern - instead of the name that the sun people use because of their ignorance of the pattern community) are terms that aren't tied to J2EE in any way.

[Ilja Preuss]

Originally posted by Mr. C Lamont Gilbert:
I won't give a concrete example of what bad could happen.

Bummer.

Thats like asking to give an example of what bad happens if you violate OO principles.

Mhh, I'd think that I could give an example of what bad could happen if you violate a specific OO principle.

But if you don't feel like it, I'm OK with it.

[quote}My point about BO and TO is that I see this conflation recommended mostly by people whose BOs only have getters and setters like their TOs.

Well, rest assured that I'm not one of those...

Therefore, my BOs expose data in a format that would not be saveable by any DAO. If I were forced to conflate them I would have to alter the way my BOs expose data.

I'm not sure that you would be forced to - although I'm also not sure that doing so would be really a really bad idea.

On the other hand, I wouldn't feel too bad using reflection to access private fields for persistence purposes, if nothing else comes to mind.

[Darya Akbari]

Originally posted by Ilja Preuss:

Uh, no, not at all. Both the terms BO and TO (or in fact *Data Transfer Object*, which is the actual name of the pattern - instead of the name that the sun people use because of their ignorance of the pattern community) are terms that aren't tied to J2EE in any way.

First of all, you came up with the term DTO not gundum hoi (whom I miss here ). J2EE belongs to Sun and of course I prefer how Sun thinks about it. BO and TO are wordings used by Sun. Even more, they describe J2EE patterns promoted by Sun.

I wonder how you get that Sun people are ignorant to the pattern community . Can you elaborate here a little more? To me this would mean that you put J2EE patterns in general into question.

Regards,
Darya

[Ilja Preuss]

Originally posted by Darya Akbari:
First of all, you came up with the term DTO not gundum hoi.

In this thread, yes. Did I suggest otherwise?

What I tried to say is that the general name for what Sun calls TO is in fact DTO.

J2EE belongs to Sun and of course I prefer how Sun thinks about it.

I'm not sure what you mean by that. But I'm surely not a big fan of Sun in general.

BO and TO are wordings used by Sun. Even more, they describe J2EE patterns promoted by Sun.

Yes, those are the words that Sun uses, and yes, they are promoted as J2EE patterns.

Still BOs have been around for a long time before the J2EE patterns. They aren't at all specific to J2EE, although they are of course as usefull there as everywhere else.

TOs where first called Value Objects by Sun. Then they discovered that the name was already in use by the patterns community. They also discovered that the pattern they were describing in fact already had a name in the pattern community: Data Transfer Object. For reasons that are unclear to me, they then decided to refer to the pattern by the TO name.


See http://c2.com/cgi/wiki?BusinessObject and http://c2.com/cgi/wiki?TransferObject

I wonder how you get that Sun people are ignorant to the pattern community .

I hope the above gives you an idea of the why.

Another thing is that they totally ignored how patterns actually come into being. Patterns aren't created by a few, they are discovered by a community. It's quite a culture clash, as far as I can tell.

To me this would mean that you put J2EE patterns in general into question.

Well, I'm not very fond of them, true.

Mind you, I'm not saying that they are generally useless. But I think there is a lot of unwarranted hype around them.

[Darya Akbari]

Hi Ilja,

thanks for sharing some light on your thinking of Sun. But wasn't it you again who said that gundum hoi for sure already entered J2EE?

If you yourself accepted that we are in the J2EE arena, why don't you adapt yourself to J2EE's inventor way of thinking. Isn't it always better to use a framework (like J2EE is one) the way the inventor thought it should be used?
Why not following the path of least resistance?

J2EE patterns are very well accepted by the community if you count Martin Fowler and Grady Booch as members of this community . BO and TO are part of these J2EE patterns.

I think to help gundum hoi getting a clearer picture is to stay in the J2EE arena and no to confuse him with DTOs, theories, etc.

Regards,
Darya

[Ilja Preuss]

Originally posted by Darya Akbari:
If you yourself accepted that we are in the J2EE arena, why don't you adapt yourself to J2EE's inventor way of thinking. Isn't it always better to use a framework (like J2EE is one) the way the inventor thought it should be used?

I'm not sure I'm following you. Are you suggesting that every system that uses Servlets should therefore also use EJBs???

BO and TO are part of these J2EE patterns.

That doesn't mean that you need to use J2EE to use the patterns.

I think to help gundum hoi getting a clearer picture is to stay in the J2EE arena and no to confuse him with DTOs, theories, etc.

I'm not sure what's confusing about DTOs, as they are exactly the same as TOs. It's simply the name Martin Fowler gave it, even before J2EE patterns existed.

I also don't see what theories you are referring to.

I'm just trying to give the best advice I can give, which in this case is actually quite simple: if you don't have remote calls in your system, try to do without (D)TOs - it will reduce the complexity of the system.

[Mr. C Lamont Gilbert]

Originally posted by Ilja Preuss:


I'm not sure that you would be forced to - although I'm also not sure that doing so would be really a really bad idea.

On the other hand, I wouldn't feel too bad using reflection to access private fields for persistence purposes, if nothing else comes to mind.

Because you are not the first to suggest this, I have considered using reflection for this purpose. But the issue is more complicated as my TO/DAO whatever to call them, actually track state change to know when they need saving and which objects need to be created in the db. Database management type stuff really. So if I did away with my TO/DAO, then I would have to bake the state change monitoring into the BO. That would really make my BOs become huge. I could do it but I think the BO would become very overworked and huge.

Furthermore, this change always involves changing from my BOs using the DAOs to get the TOs, to my DAOs returning the BOs. So this turns my BO/DAO relationship inside-out. I tried once. I'm still looking at it, but hesitant to try again. My objects have lots of relationships with each other that are tricky to track.

And also, I would have to modify the BO for each DAO. When I use JDO, I would have to have a set of BOs from JDO. When I use JDBC DAOs that would require a different implementation of the BOs and again hibernate DAOs would require a 3rd implementaiton of the BOs. I don't mind recreating persistence code for each DAO, but i would hate to recreate business code because I am adding a new DAOs implementation. I know folks do this it seems but I can't understand how/why?


P.S. I am also one who believes Sun is off their rocker with the patterns. I recently critized them on the forums for renaming their VO pattern. What they call TO in their DAO pattern is not even the same as what they call TO in their TO pattern. Plus in theirn "TO" pattern all the pictures still have "ValueObject" written on them...
[ August 14, 2006: Message edited by: Mr. C Lamont Gilbert ]

[Ilja Preuss]

Originally posted by Mr. C Lamont Gilbert:
Because you are not the first to suggest this, I have considered using reflection for this purpose. But the issue is more complicated as my TO/DAO whatever to call them, actually track state change to know when they need saving and which objects need to be created in the db. Database management type stuff really.

In my understanding, (D)TOs are pure data holders - data structures without any behaviour. If I understand correctly, you don't use them that way?

So if I did away with my TO/DAO, then I would have to bake the state change monitoring into the BO.

I'm not arguing for doing away with DAOs. I'm sure that there are other alternatives than baking the state change monitoring into the BO, though.

Furthermore, this change always involves changing from my BOs using the DAOs to get the TOs, to my DAOs returning the BOs. So this turns my BO/DAO relationship inside-out.

I don't think I understand what you are getting at here.

And also, I would have to modify the BO for each DAO.

That would in fact be bad. I don't see why it would be true, though.

When I use JDO, I would have to have a set of BOs from JDO. When I use JDBC DAOs that would require a different implementation of the BOs and again hibernate DAOs would require a 3rd implementaiton of the BOs. I don't mind recreating persistence code for each DAO, but i would hate to recreate business code because I am adding a new DAOs implementation.

I don't understand why you think you needed to do this. I'm quite sure that hibernate can work directly on BOs, without the BOs having to know about it.

[Darya Akbari]

Originally posted by Ilja Preuss:
from http://www.martinfowler.com/bliki/LocalDTO.html

DTOs are called Data Transfer Objects because their whole purpose ...

It all depends whether gundum hoi uses the J2EE or not. In case he does use J2EE of what help is your hint about DTO? Is the description somehow related to J2EE? I don't think so :roll: . All I say, as I said from begin on, is only valid if gundum hoi uses the J2EE approach. Reading your link will not help him to implement a J2EE solution, right? Your DTO link is only about theory and not related to an J2EE solution.

On the other hand I give him the BO and TO J2EE patterns at hand so that if he follows the J2EE description/examples for these patterns he has a tangible result which follows J2EE best practize.

By the way, did you recognize that gundum hoi already left the party

Regards,
Darya

[Peer Reynders]

Originally posted by Darya Akbari:
By the way, did you recognize that gundum hoi already left the party

While you are probably right, there is the possibility that gundum hoi is still lurking out there. Furthermore these topics often serve as "stage" for the exchange of different views regarding common technical challenges. This benefits all topic participants and hopefully some later visitor who has the sense to use Google or the JavaRanch forum search.

Originally posted by Darya Akbari:
It all depends whether gundum hoi uses the J2EE or not.

.
Well the original post doesn't mention J2EE as such. It merely states that the question relates to "a fairly simple webapp". I assume that you extrapolated the use of J2EE because the original post uses the J2EE specific terminology of "Business Object" and "Transfer Object", rather than the terminology of the general pattern community of "Domain Object" and "Data Transfer Object". Other than that there really is no evidence that the original post seeks to implement anything else than a simple servlet + POJOs solution.

Ilja simply pointed out that the general pattern community has in fact identified that the premature adoption of the TO/DTO pattern is in fact to be treated as an anti-pattern. It increases complexity and the need for coarse grained interchanges makes the system less object-oriented. This is a cost that should only be incurred if there is an equal or greater compensating gain. J2EE doctrine promotes the use of TO/DTOs between tiers so that your application can be distributed when it "becomes necessary". However experience has shown that distributing your application does not necessarily make it more performant - usually designing an application to be clusterable (parallel vs. serial deployment) is far more effective. So de facto use of TO/DTOs, as promoted by J2EE doctrine, is just another case of "Your Aren't Going To Need It" (YAGNI).

Furthermore usage of J2EE best practices is recommended in general, unless these best practices are motivated by the "wrong" set of assumptions. For a blow-by-blow discussion why physical separation of tiers (which is why you would use TO/DTOs) is a bad idea in 80% of the cases see Rod Johnson's Sample Chapter of Expert One-on-One J2EE Design and Development: Chapter 1 J2EE Architectures. Now his discussion relates to EJB 2.1 but the arguments against distribution remain the same. And even Chris Richardson labels EJB 3.0 as a "heavy-weight" solution in "POJOs in Action". So EJB really has no place in "a fairly simple webapp" and while there are other means of "remoting" it is not likely that any of those would be employed here.

Now sometimes TO/DTOs are employed in a local deployment to reduce the coupling between the logical tiers. However the OO development community at large would probably argue that it would be wiser to define separate interfaces, some facing the integration tier and others facing the business tier which can all be later implemented either by the domain objects themselves or a by a setup that uses TO/DTOs, brokers and domain objects.

Darya, this isn't the Architect Certification (SCEA) forum, so use of J2EE is neither mandated nor is the toolbox limited to J2EE. The solutions discussed here will likely only use aspects of J2EE that add tangible value during design, development, and/or deployment for that particular solution in its particular environment.

Now with your SCEA preparation your are immersed in Sun J2EE doctrine. In your practical work however you may need to be a bit more critical about the best practices promoted by the folks from SUN, Hibernate, Spring, etc. Before adopting any patterns and best practices in your particular situation, verify that the assumptions that those patterns or best practices are based on still hold.

Originally posted by Darya Akbari:
If you yourself accepted that we are in the J2EE arena, why don't you adapt yourself to J2EE's inventor way of thinking. Isn't it always better to use a framework (like J2EE is one) the way the inventor thought it should be used?
Why not following the path of least resistance?

J2EE patterns are very well accepted by the community if you count Martin Fowler and Grady Booch as members of this community . BO and TO are part of these J2EE patterns.

In general J2EE patterns are actually limited to situations that typically only arise because of the idiosyncrasies of the J2EE architecture - "to get around J2EE's weaknesses" as some have phrased it. In some cases J2EE patterns establish different (possibly confusing) names for already existing patterns which causes some confusion (eg. TO, VO). In other cases the pattern can be quite vague (DAO vs. Table Data Gateway, Row Data Gateway, Data Mapper).

See also Value Object (VO) vs. Transfer Object (TO) vs. Data Transfer Object (DTO).
In my opinion communication is better served when you use the more widely accepted patterns and their names (DTO) rather than the J2EE specific ones (TO or worse VO) and save J2EE patterns for the J2EE niche aspects. Unfortunately it seems that some developers first exposure to patterns is through J2EE patterns, who then operate under the assumption that these are the patterns for enterprise applications in general, which of course isn't true.

In my opinion J2EE pattern can only be effectively used if you have equally balanced knowledge of J2EE AntiPatterns (amazon US) which unfortunately isn't part of the SCEA curriculum either.

Originally posted by Mr. C Lamont Gilbert :

TO shows a clear seperation of behavior from a BO. I can't see anyreason to conflate these two.

Given the "right" circumstances. However one could argue that the definition of separate "integration tier facing interfaces" and "business tier facing interfaces" may actually make a better "clear separation". Then you can delay the decision to whether you will have your domain object implement those interfaces or some other set of objects. Furthermore object-oriented principles seek to collocate related data and behavior rather than separate it. DTOs still mainly exist as serializable data containers for flattened composite object structures that are typically exchanged between the necessarily coarse-grained interfaces between remote points of a distributed system.
You are rightly concerned about the violation of the "Single Responsibility Principle" when your domain objects have to worry about persistence issues. That's why ORMs (like Hibernate) do it for you behind the scenes. Alternately you could use something like AOP (AspectJ) to inject the persistence aspects into your domain objects (a decidedly advanced technique).

[Ilja Preuss]

Not much to add to Peers excellent essay...

Just one thing, to makes this totally clear:

Originally posted by Darya Akbari:
It all depends whether gundum hoi uses the J2EE or not. In case he does use J2EE of what help is your hint about DTO? Is the description somehow related to J2EE?

Yes, it is. The DTO pattern is *exactly* what is called the TO pattern in the J2EE community. So any advice regarding the DTO pattern applies directly to the TO pattern, too.

Your DTO link is only about theory

Huh? How do you come to *that* conclusion???

On the other hand I give him the BO and TO J2EE patterns at hand so that if he follows the J2EE description/examples for these patterns he has a tangible result which follows J2EE best practize.

Using a (D)TO is only best practice when the forces mentioned in the pattern description are present. Going blindly for a (D)TO just because you are using J2EE isn't, sorry.

By the way, that's true for every single pattern out there. Applying patterns isn't a good thing per se. Every pattern has a context in which it makes sense to use it - using it outside that context is typically worse than not using a pattern at all. And the context of the (D)TO pattern is the avoidance of successive small grained remote calls.

[Mr. C Lamont Gilbert]

Originally posted by Peer Reynders:

...
You are rightly concerned about the violation of the "Single Responsibility Principle" when your domain objects have to worry about persistence issues. That's why ORMs (like Hibernate) do it for you behind the scenes. Alternately you could use something like AOP (AspectJ) to inject the persistence aspects into your domain objects (a decidedly advanced technique).

Im not sure what AOP is but I in essence have the persistence handler injected into my BOs. I don't really use DAO pattern because it does not work well with a tree-like BO heirachy.

Tricky part is when doing a JDBC implementation with a DAO pattern, you will need to give your BOs some way for the DAO to tell if its been saved to the db or not. So you end up adding something to the BO strictly for persistence reasons... Yea, JDO and Hibernate hide this. But its there. Which is the essence of why I don't like JDO / hibernate touching my BOs. I prefer to inject some persistence object into the BO, and the BO _never_ has to change or be enhanced or even reflected.

[Stan James]

If your BOs publish some event (observer/observable) on data change then some other object can monitor the state, eg which fields/columns have been changed. (I always grin when I set the "dirty bit" but I'm easily entertained.) That can keep your BO well separated from persistence info.

[Gundum Hoi]

Hi all,

I think I can't thank enough, even if I say thank you a thousand times for answering my question & for helping me.

Please be rest assured that your efforts are not "wasted" in anyway as I had, am and will be reading each and every word here with much care.

I will post more later... although I have read through all posts, I need a little more time to analyse and digest all that were written here...as I believe all are good stuff, good solid discussion.

Most of all, it certainly helped me in my understanding.

A BIG THANK YOU TO ALL.

[Gundum Hoi]

Also let me give a few points:

- DTO, TO and VO are all the same thing. It is sad that this multiple-term-for-the-same-thing problem exists in the patterns community because, the whole purpose of having this thing call "design patterns" is to have common terminologies, to ease discussion - so that software engineering can proceed to a higher level. We can't even settle on terminology how can software engineering advance ? Or, put it in another way, software engineering is so difficult (compared to all other engineering fields) till... the industry cannot even settle on basic stuff like terminology.

- After reading, and re-reading and re-reading and re-reading the "Core J2EE Patterns" book again and again, now I understand that TO/DTO/VO is nothing more than a bucket to store data for transfer purposes only (and no other purpose ! I have to resist my temptation to use it for more than that.) And because it is only a bucket and nothing more, I now understand why the "Core J2EE Patterns" book codes TO/DTO/VO as a class with no methods (yes, no methods at all...not even getters/setters)...but only all public fields to store data for transfer. Humm.... so simple...just the bucket idea ... yet caused so much confusion. I can see that TO/DTO/VO really helps when comes to remote calls and passing data during remote calls, but even local calls can really benefit from TO/DTO/VO.

Instead of doing :
1) someMethod(param1, param2, param3, param4, param5...param x);
it is much better to use a TO/DTO/VO and do this :
2) someMethod(param1); where param1 is a TO/DTO/VO

the TO/DTO/VO way is much easier, cleaner (less params), and more importantly much more meaningful...because :
In 1), you often don't know what each param is for,....you have to check the API or read the code of the method you need to call.
In 2), you set data into TO/DTO/VO meaningfully... eg dtoJavarancher.name="Ilja Preuss", dtoJavarancher.rating="5 star" etc etc...and then just pass the dtoJavarancher TO/DTO/VO to the method you are calling - just 1 param.

I hope I am understanding all these correctly. But then, if I am correct with the above, why Martin Fowler is so against TO/DTO/VO in local method calls ? It is so obvious that TO/DTO/VO is so beneficial EVEN for local method calls.

(Btw, Ilja Preuss is just an example above, every Javarancher is equally cool !)

[Gundum Hoi]

By the way....the "bucket" idea/term for TO/DTO/VO... I coined it myself, based on my understanding of it... and I use it to explain to my fellow programmers...and those people...amazingly understood TO/DTO/VO with just a single word !

But, I'll have to make sure that I understand TO/DTO/VO properly myself...and your valued input/confirmation is very much appreciated.

[Ilja Preuss]

Originally posted by gundum hoi:
DTO, TO and VO are all the same thing. It is sad that this multiple-term-for-the-same-thing problem exists in the patterns community because, the whole purpose of having this thing call "design patterns" is to have common terminologies, to ease discussion - so that software engineering can proceed to a higher level.

Yes, it's sad. Fortunately, it doesn't happen often. (Another example is perhaps Inversion of Control vs. Dependency Injection, although some argue that those are two different things.)

The usual process for naming a new pattern is that the "author" asks in the pattern community whether it's actually a pattern (that is, others have already used/seen it, too) and whether it's new.

It seems that the authors of the J2EE patterns skipped that step, which is unfortunate. Why they then, after seeing that the pattern already had a name, decided to use a *third* totally escapes my understanding (and my sympathy, for that matter).

After reading, and re-reading and re-reading and re-reading the "Core J2EE Patterns" book again and again, now I understand that TO/DTO/VO is nothing more than a bucket to store data for transfer purposes only

Yes! Oh, yes, yes, yes!

Instead of doing :
1) someMethod(param1, param2, param3, param4, param5...param x);
it is much better to use a TO/DTO/VO and do this :
2) someMethod(param1); where param1 is a TO/DTO/VO

Yes, that can be a good idea, but the intention - and therefore the forces on the code - are a bit different from DTO. Therefore this is a pattern with its own name: Parameter Object.

A DTO is supposed to be a pure data bucket, and we put data together in a DTO for performance reasons - we put those things together that are needed for one method call.

With a Parameter Object, we are typically more concerned with cohesion - we prefer to put data together in a Parameter Object that logically belongs together. We are much less concerned if that leads us to passing two objects to a method instead of just one, or something.

Also, quite in contrast to a DTO, optimally a Parameter Object doesn't keep being a stupid data bucket. Often it is possible - and beneficial - to move operations on the data into the Parameter Object itself. You would never do such a thing with a DTO. (See also http://www.refactoring.com/catalog/introduceParameterObject.html )

Does that sound reasonable?