What is a value object? Why would I use one? What are some problems with them?

Alex Chaffee

A Value Object, aka a Bulk Accessor or Bulk Data Class, is a lightweight Java class, separate from your EJB class, that contains properties or instance variables corresponding to each of your EJB's properties.

Paul Done, in feedback to Is there any reason why value objects cannot have set methods?, defined value objects very well:

Value objects are recommended when data has to be returned from an EJB server to the EJB client, if none of the data has to be updated. ie. The value objects are used to transport read-only data.

It is the equivalent of the client requesting XML from the server tier, except you get the tighter compile time binding and control, and you don't have to parse the returned XML.

If, instead, an equivalent EJB reference with the same 'getter' methods is returned, then each time the client calls a getter method on the reference EJB, this results in a remote method call to the server tier. This is an uneccessary round trip, when the object could have held the data locally itself.

So basically, value objects are recommended to enable your multi-tier application to be more performant.

If you do need to update data, then you may need to use an EJB reference instead. However, this fine-grained querying/updating of data could become a severe performance bottleneck, if lots of it is performed. The traffic between different tiers needs to be minimised. Instead, EJBs should be used by clients for more coarse-granied method invocations.

For example, the client could call a session bean on the server to get a complex data set (encapsulated in a value object), instead of just 1 row of data from 1 table. The server session bean may have used many entity beans or jdbc directly, behind the scenes on the server tier; however, this is hidden from the client. Once the client recieves the complex value object, it can do as many local method calls as it likes on it to get the data. Then a new (or the same) object could then be constructed with all the updated data. The client would then pass this object back to the server, to perform the update, by calling the appropriate method on the remote session bean, passing the new value object as the parameter.

EJB/RMI is sometimes touted as a way to write a multi-tier application, as if it is a single tier application , without having to architect your design to cope with cross-tier communications. In reality, though, any design has to compromise to take account of these cross-tier performance issues.

One problem with using Value Objects is that they are indeed passed by value, not by reference. If the data are updated on the server, a client may be accessing an out-of-date value stored in his local copy of the value object. Furthermore, if you use value objects to *store* data back on the server, you may inadvertently be reverting changes to fields that you did not set, but that a different client changed in the meantime.

Another is that it is simply annoying to write one! It's like, I just wrote all these accessor methods on the *real* bean, and now I have to write them again on this fake one! Also, as you upgrade your bean code, you need to remember to update your value object code as well, leading to possible subtle migration bugs.

EJBDoclet is an open-source product from DreamBean Software than allows you to generate various EJB-files from a commented bean source-file, including a bulk data class. This somewhat mitigates the previous complaint.

See also: