• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Devaka Cooray
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
Bartenders:

Regarding Entity beans and value objects

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,
How do Entity beans differ from value objects. Excluding the differences that entity beans run inside a EJB Container and the various services that the container provides to them.
As far as i know the value objects are just plain and simple java objects containing set and get methods for each of their attributes and do not contain any SQL inside any of the methods which a Entity bean(BMP) may have.
The similarity is that both have getter and setter methods.
I need to clarify myself whether value objects can be a replacement for Entity beans. If that is not the case then, can both work in collaboration and if yes then how.
What scenarios can really force one to adopt the value objects as part of the solution.
 
prabhu gupte
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Isn't it that the FormBeans that are part of Struts Framework behave like value objects since, apart from being a grab bag of all the related fields inside the FormBean they also have certain validations to make sure the fields that are part of the FormBean are valid as per business rules. Also value object pattern recommends its use only when two layers need lot of data to be exchanged between them and theres a need to keep this transfer manageable. Related pieces of data can be clubbed in to a single VO and method calls can then use these VO as arguments.
Am i right?
 
Bartender
Posts: 1167
20
Mac OS X IntelliJ IDE Oracle Spring VI Editor Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Am i right?" - Yes, VO (or transfer objects) can improve the design of a system, and tend to be used with EJB's. A few advantages: Reduce network traffic, transfer more data in fewer remote calls (etc) - It's a J2EE dedign pattern; google will provide you with much more.
Core J2EE Patterns - Transfer Object.

"two layers need lot of data to be exchanged between them" - yes, can produce cleaner code, if used in the same layer (IMHO).

Also, have a look at the Hibenate / JDO frameworks (their is forum on JavaRanch). Lastly you should know that the new EJB3 specification is going to make things a lot simpler (thankfully!).
 
Ranch Hand
Posts: 278
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Using VO insures Course Granied rather than Fine-Grained, with lot of advantages as discussed above.
Course grained is one large object to do many things.
Fine grained is spreading those responsibilities among many smaller classes.

 
Where does a nanny get ground to air missles? Protect this tiny ad:
Paul Wheaton's 16th Kickstarter: Gardening playing cards for gardeners and homesteaders
https://coderanch.com/t/889615/Paul-Wheaton-Kickstarter-Gardening-playing
reply
    Bookmark Topic Watch Topic
  • New Topic