Posted in: J2EE Design Patterns,Java Design Patterns
Value ObjectIn this chapter, we are going to take a detailed look at the Value Object Pattern.
What is Value Object Pattern?
The Value Object pattern provides the best way to exchange data across tiers or system boundaries, especially when there is network communication involved. This is a pattern that solves performance issues around network latency. Do I have to tell you that, this is a very useful pattern?
Is
This pattern is an object that encapsulates a set of values that is moved across the boundary so that attempts to get the values of those attributes are local calls.
Is Not
This pattern is not a concrete object. You wouldn't use it to create an object. You could use it to hold values of that object.
Analogy
This would be like placing several letters in a box to be mailed once a week instead of mailing the letters separately and multiple times over the week. The box is mailed once. When the box arrives, the mail carrier can just reach in the box for the next letter; she doesn't have to contact the origin, which would take a long time.
Problem
In J2EE, server-resident business applications often use session beans and entity beans. The session beans are responsible for functionality that is involved in one-to-one transactions with the client. In contrast, the entity beans are used to handle persistent data. So, the client will make many calls to the session bean to get data. That represents a lot of traffic, to and from a remote location because the bean may be at a server at a remote location. Likewise, the session bean may make many calls to the entity bean getting and setting attributes. The Value Object pattern encapsulates the data fields of an entity bean; VO has nothing to do with session beans (except that it is usually a session method call that returns a VO, instead of a remote entity reference).
This activity is inefficient. We need a way to eliminate all these potential network calls reducing overhead and providing a more direct access approach.
Responsibility
This pattern provides a mechanism to exchange many remote calls to local, direct calls.
Aim
This pattern attempts to reduce the network overhead by minimizing the number of network calls to get data from the business tier.
Primary Activity
Used to collect remote data into an object that is sent to the client, so now the client makes local calls to get values rather than remote ones.
Context
Multi-tier applications that need to exchange sets of data between the client and server often.
Benefits
• J2EE applications often use enterprise beans. All calls to these beans are performed via remote interfaces to the bean due to Java's architecture. This introduces overhead.
• The frequency of reads is greater than updates because the client gets the data from the business tier for presentation.
• The client usually needs a set of data, not just one attribute.
• Client calls to enterprise beans accessed over the network affects WebApp performance because of the sum of network latency of multiple attribute access to the entity bean.
• Regardless of Java's bean architecture, it would be better to collect attributes into one object and get them from it rather than make invoking remote methods for the same information.
Usage
This pattern is useful when you need a collection of data from a remote source or, more likely, when a client has to make several calls for data from entity beans.
Consequences
• Simplifies Entity Bean and Remote Interface— Sun suggests using getData() and setData() methods on certain entity beans as a way to get and set a value object containing the set of attribute values. Calling the getData() method once replaces multiple calls to get methods. Likewise, the setData() method replaces many set calls.
• Using this pattern transfers a set of values in one method call improving overall performance, especially over the network. It represents coarse versus fine-grained interfaces.
• The client can update, delete, and read the values that are now local at will. When done, it can update the data source in one call. However, there may be a problem with synchronization as the other clients won't know about the changes until the update call. In the case of updates, there can be two conflicting update calls by two clients, so this must be synchronized somehow.
Uses
The ResultSet of JDBC is a collection of data returned from the data source resulting from a query. The data is now local in the ResultSet object so all calls to it are local rather than many calls to the data source directly.
Other Related Patterns
• Aggregate Entity that uses Value Object to get data across tiers.
• Session Façade, which is the business interface for clients of J2EE applications. This pattern often uses value objects as an exchange mechanism with participating entity beans.
• Value List Handler is another pattern that provides lists of value objects constructed dynamically by accessing the persistent store at request time.
• Value Object Assembler builds composite value objects from different data sources. The data sources are usually session beans or entity beans that may be requested to provide their data as value objects.