The DOM Is Not the Same As a Value Object
The important thing to understand about the DOM Pattern is that it is not the same as the Value Object
(often called Data Transfer Object) Pattern. The Value Object Pattern was created to overcome a
shortcoming in the original EJB specification that meant that all calls to an EJB were remote. Configuring
the state of an EJB typically means many calls, all of which are remote. Using a value object, object state
is transferred in bulk using a single remote call, thus reducing the performance hit of making many
remote calls.
■ Note Officially the Value Object Pattern is not the same as the Data Transfer Object Pattern. Martin Fowler
defines a value object as "a small simple object, like money or a date range, whose equality isn't based on
however, from the Core J2EE Patterns catalog that uses the term value object for many of the examples of the
Data Transfer Object Pattern. (For details, please refer to "Core J2EE Patterns: Transfer Object" and the Transfer
/TransferObject.html.) In this section, we use the terms value object and data transfer object interchangeably,
but we are talking about the Data Transfer Object Pattern.
A DOM is an object-based representation of the application problem domain, intended to allow the
programmer to code in terms of objects that exist in the problem domain. While a value object purely
encompasses state, it is perfectly acceptable for a domain object to encompass both state and behavior
(although you may choose not to encapsulate behavior inside domain objects).
Another key difference between domain objects and value objects is that a value object's structure is
driven by the need to transfer data remotely, whereas a domain object is modeled to represent a real-
world concept and is not driven by some need of the application infrastructure. As we discuss later, we
believe there are no hard-and-fast rules for modeling domain objects; you have to choose a level of
granularity that matches your application and the functions it will perform.
It is possible for an application to have both domain objects and value objects. In this approach,
value objects are used by the service layer to communicate with other layers, such as the presentation
layer and the data access layer. These value objects are then converted as appropriate into domain
objects and passed into the presentation layer for rendering. In general, this approach is not
recommended. One reason is that maintenance will be complicated, because changes to domain objects
also mean changes to the related value objects. The other reason is that with Spring, the data access and
web framework is so powerful that it is simple to map data directly to domain objects, both for
processing and for presentation.
Why Create a Domain Object Model
Creating a DOM requires some up-front effort in order to identify domain objects and then create an in-
code representation of these objects. However, this up-front effort is far outweighed by the time you will
save and the bugs you will avoid when it comes to implementing business logic to do something with
your domain objects. We find that using a good DOM makes creating the code to solve business
problems much easier, since you are able to code in terms of the problem rather than in terms of the
machine the application runs on. A good DOM makes it easier for developers to transform application
requirements into application features.
Search WWH :
