Practical Design Considerations
Thanks to the evolution and maturity of various persistence technologies and Spring's flexibility in
integrating with those technologies, the task of designing and building a data access layer is much
simpler these days. Practically, the most difficult and time-consuming task is to perform mapping
between the underlying database structure and the DOM in the application. However, you should bear
in mind a few practical considerations when creating your data access layer that will help you build data
access logic that is simpler to use and easier to extend.
Domain Objects or Data Transfer Objects?
Most of the time you don't need to rely on DTO for shipping data between different layers. As discussed
earlier this chapter, nowadays all popular persistence technologies and JEE itself supports using POJO as
the underlying DOM, making it possible for the service layer, presentation layer only, and data access
layer to communicate using domain objects directly.
Since all domain objects are now POJOs, they can be easily supported by frontend presentation
frameworks (e.g., Spring MVC, JSF, Adobe Flex, to name a few) to directly interact with the service layer
via domain objects.
However, in some cases, the DTO Pattern is still worth considering. For example, a domain object
contains many long text data attributes that may not be required to send to the frontend for every
request. In this case, it is worth considering whether to create a value object that stores only the exact
attributes required by the corresponding frontend in order to minimize the data transfer between the
presentation layer and service layer.
DAO Interfaces
As a rule of thumb, always define your DAOs (if you decided to go for the DAO Pattern) in terms of
interfaces, not classes. When writing code in your service objects to work with your DAOs, code to the
interfaces, not the implementation classes. Remember that when you are using Spring, it is a trivial job
to pass an instance of the appropriate DAO implementation to your service layer, so using interfaces for
your DAOs places very little additional coding burden on you.
DAO Granularity
When deciding how to structure your DAO interfaces, definitely avoid creating one DAO per domain
object and one DAO per table. Sometimes, these structures appear naturally after thoughtful design, but
don't assume that either one of these structures is necessarily the best.
A big problem we often see with projects is the "one DAO per table" problem. When you define a
structure like this, you end up with DAOs representing join tables that serve no purpose other than to
join two other tables in a many-to-many relationship. Plus, you often find that you have to pass a single
domain object to lots of different DAOs to have the data persisted.
This is a classic example of letting the database drive the design of your DAO layer. This is something
that, in practice, we have found to be a bad idea. The purpose of a DAO is to map domain objects to the
database, and vice versa. Because the bulk of your application is interacting with the domain objects, not
the database, it makes sense to let the DOM drive database design. Let your DAOs hide the complexity of
mapping the data in your domain objects to the database; that is their job. You are trying to avoid the
situation where persisting a domain object requires you to interact with many different DAOs. Situations
like this arise naturally, such as when a domain object has a reference to another domain object of a
different type and both have been modified and thus need to be persisted. In this case, you can
encapsulate that logic in your service layer, but you do not need to create this problem artificially.
Search WWH :
