File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Use of value objects in your EJB apps Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Use of value objects in your EJB apps" Watch "Use of value objects in your EJB apps" New topic
Author

Use of value objects in your EJB apps

Bill Pearce
Ranch Hand

Joined: Sep 19, 2000
Posts: 53
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
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
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).]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Use of value objects in your EJB apps