Forums Register Login

Use of value objects in your EJB apps

+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
 

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).]
So I left, I came home, and I ate some pie. And then I read this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1090 times.
Similar Threads
My SCEA Part 1Study Notes
When will call ejbActivate and ejbPasivate ?
opinion: Data Transfer Objects: pattern or anti-pattern (EJB3)
To Nikhil Pendharkar for IBM 287
IBM 287 ICE TEST
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 12:43:59.