• 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:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Use of value objects in your EJB apps

 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
We are working on an internal API to create customers and orders in our system using EJB. I have read in the blueprints about value objects, and I'm all for them when it comes to getting or updating data that can be logically grouped together. For example, instead of getting and setting the customer firstName, lastName and phone, get and set a customer value object with all relevant data in it.
But I am a little worried that some here are taking the value object concept a little too far. Some have proposed designs that have the client API operating only on value objects, and only communicating with a single bean to update or add an entry, passing a value object in as a single parameter. This is done they say for the sake of performance.
This bothers me because the client has no validation whatsoever on the value objects themselves. So the client calls all these set methods, adding data to these objects (which contain other value objects, which they also construct and add data to), and calls a single method like addOrder(OrderValueObject). This is the only time the client is made aware of any business rule violations, since they never talk to any beans directly. This also adds more classes to maintain and worry about when changes are made.
These people here also have all the set methods on thier value objects, which I don't like (and the blueprints advise against). To me, this gives has the potential for giving the client the (wrong) impression that when they call setCustomerPhone() that they have updated the customer's phone number, which they of course have not. The blueprints state that value objects should be immutable, with constructors and get methods only, in order to prevent the client from making this mistake.
Does anyone else use value objects to this extent? Do any of you go out of your way to prevent a client (servlet, java app, whatever) from calling any of your beans directly? Maybe I think this is too simple, but what is wrong with a servlet programmer looking up my bean and talking to it?
If you are not familiar with the term value object, it is just a simple class that holds some values so they can be serialized and moved from client to server, grouping related data together, like Address and CreditCardInfo.
Any input is appreciated. Sorry if I have rambled, I'm a little frustrated.
Bill
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bill Pearce:
[...] Some have proposed designs that have the client API operating only on value objects, and only communicating with a single bean to update or add an entry, passing a value object in as a single parameter. This is done they say for the sake of performance.
This bothers me because the client has no validation whatsoever on the value objects themselves. [... Submission of the value object] is the only time the client is made aware of any business rule violations, since they never talk to any beans directly. This also adds more classes to maintain and worry about when changes are made.
The blueprints state that value objects should be immutable [...], with constructors and get methods only, in order to prevent the client from making this mistake.
Does anyone else use value objects to this extent?


Yes - although not exactly in the way you describe it.
The idea behind using value objects is just as valid for updating data as for retrieving data: EJB calls are heavyweight. You don't want your presentation layer to call the EJB tier a hundred times for what is essentially a single update. Moreover, you often want those updates to be done in a single transaction. This is most conveniently done as a single call to a session bean.
As you noted, there are definite risks, class bloat and a confusing API among them. These risks are greatest, I think, if your value objects are just mirrors, or subsets, of your EJB. When they are self-contained, coarse-grained data types -- say, an Address object -- there are far fewer dangers and ambiguities (you wouldn't be confused about an int, why would you with an Address?)
This also clears some of the business logic responsibilities: it is perfectly OK for an Address object to impose validation on addresses. Again, self-contained is the keyword; any validation whether an Address which is in itself valid would be OK for a customer should be postponed until the customer.setAddress(address) call (where customer is an EJB).
On the other hand, when a value object is a mere mirror of (part of) an EJB, I would tend to make it immutable for the reasons you mention.

Do any of you go out of your way to prevent a client (servlet, java app, whatever) from calling any of your beans directly? Maybe I think this is too simple, but what is wrong with a servlet programmer looking up my bean and talking to it?


Call overhead and transactional control.
- Peter

[This message has been edited by Peter den Haan (edited April 30, 2001).]
 
We must storm this mad man's lab and destroy his villanous bomb! Are you with me tiny ad?
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic