• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Value bean and Transfer Object

 
Sridhar Raman
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just wanted to clarify my understanding on these two objects. They both seem to essentially mean the same from the perspective of the View object.
A Transfer Object is usually a Value Bean Object and is used by the View for displaying the content.
A ValueBean is used by the View for displaying the content. but it may not be a Transfer Object. It could just be a code fragment encapsulated as taglib and have no connection with the business services.
Could anyone please confirm if I got this right?
Thanks in advance.
Sridhar
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to D. Alur et a., p.236, "A value bean is another name for a helper ...", i.e. a ViewHelper
- accessing the BusinessDelegate and
- allowing a View to access the attributes fetched via getter methods.
A Transfer Object is the same as a Value Object, which typically is used to transfer data between the resource tier and the business and presentation tier. Because the ViewHelper / Helper / ValueBean resides on presentation tier only, it typically is not the same as a ValueObject deriving from Resource Tier.
If you state: "A Transfer Object ... is used by the View ..." then do not forget that typically the View does this via a ViewHelper and not directly.
tomte.
 
Sridhar Raman
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Thomas. The Transfer Object could be a JavaBean and double up as a ValueBean. This approach makes a lot sense to me. You get the intermediate model and pass it on to the View. This approach has been mentioned in the Service to Woker pattern documentation of the core J2EE patterns.
Helper is a generic term. A helper could simply serve properties as in this case I am talking about. It could also be an active component that talks to business services to retrieve content.
I will be interested to hear if you have further thoughts on this.
Regards
Sridhar
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Sridhar,
I just found where your naming "ValueBean" might come from. It is the name of a concrete class in sequence diagrams like the one according to "Service to Worker" on page 219 of "Core J2EE Patterns". The name ValueBean really depicts the double role, as you wrote:
The Transfer Object could be a JavaBean and double up as a ValueBean.

And I found the stereotype <<ValueObject>> written with a pencil above that ValueBean in my book. In discussions I prefere to use common pattern names wherever possible. UML is complicated enough, and there are enough terms to know for discussing design patterns, architectures etc..

This approach makes a lot sense to me. You get the intermediate model and pass it on to the View.

1. I agree for trivial cases where the View Helper conceptionally is nothing than a Value Object, and ViewHelper:ValueObject == 1:1 .
2. Other strategies let the View Helper request the model/data from a Business Delegate ("active component that talks to business services to retrieve content" as you called it). These I would not like to mix up into one "Value Bean"; it would disturb the clear responsibilities of tiers - although ... (see 3.)
3. ... according to page 220 even "a helper may represent ... a delegate (see Business Delegate)", but that in my opinion would be the worse design. It not even takes care of the N:1 relationship intended by the Business Delegate pattern typically having ViewHelper:BusinessDelegate == N:1 . This N:1 relationship could be solved by letting the Business Delegate implement the N ViewHelpers (then being interfaces only), but this would again disturb the _logical_ responsibilities of tiers (even if the Business Delegate runs in the same JVM as the Client and/or Presentation Tier).
Do you agree?
tomte.
[ February 26, 2004: Message edited by: Thomas Taeger ]
 
Sridhar Raman
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Thomas,
See below my comments to your points.
>>>> 1. I agree for trivial cases where the View Helper conceptionally is nothing than a Value Object, and ViewHelper:ValueObject == 1:1 .
I am not talking of an overloaded helper class with multiple responsibilities. A ViewHelper can be set of collaborating objects. For assisting a single view, you could have a helper that acts as a value bean(JavaBean) and another one that talks to business services and retrieves content.

>>> 2. Other strategies let the View Helper request the model/data from a Business Delegate ("active component that talks to business services to retrieve content" as you called it). These I would not like to mix up into one "Value Bean"; it would disturb the clear responsibilities of tiers - although ... (see 3.)
I agree. Like I said above, I am really talking of a set of helpers with different responsibilities assisting a single view in presenting content to the end user.
>>>>>3. ... according to page 220 even "a helper may represent ... a delegate (see Business Delegate)", but that in my opinion would be the worse design. It not even takes care of the N:1 relationship intended by the Business Delegate pattern typically having ViewHelper:BusinessDelegate == N:1 . This N:1 relationship could be solved by letting the Business Delegate implement the N ViewHelpers (then being interfaces only), but this would again disturb the _logical_ responsibilities of tiers (even if the Business Delegate runs in the same JVM as the Client and/or Presentation Tier).

I totally agree. When I mentioned that the helper talks to the business service, I meant that it does via the business delegate.

Regards
Sridhar
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic