So, then you might wonder if you should let the DOM drive the design of the DAOs. Well, yes and
no. Yes, in that the purpose of the DAO is to get DOM data into and out of the persistent data store, so it
makes sense to let the DOM act as the driver. No, in that blindly creating one DAO per domain object
leads to a situation where the persistence of one logical unit of data leads to calls to many different
DAOs. Consider the earlier example of the Order and OrderLine objects that are created from the Cart
and CartItem objects. Because it is unlikely that you are going to want to save or retrieve OrderLine
objects without doing the same to an Order object, it makes sense to encapsulate persistence logic for
both domain objects in a single OrderDao, rather than create OrderDao and OrderLineDao.
Data Access Layer Summary
Creating a data access layer for your application provides the rest of your application components with a
standard mechanism for storing and retrieving data. Without a data access layer, you will find that data
access code becomes spread out through your application, often resulting in code duplication that is
hard to maintain. In the long term, this poorly managed code inevitably leads to bugs and developer
headaches.
Depending on the technology decision of implementing the data access layer, most of the time you
won't need to adopt the DAO Pattern anymore. Many popular persistence technologies and standards
already do a very good job of hiding all the database access details for you. So, it's recommended that
you inject those persistence providers to the service layer directly. This will simplify the application
architecture, as well as result in code that is easier to trace and maintain.
In case you decided to use DAO or it's the standard that your team or company has standardized on,
you should always define DAOs as interfaces and then implement these interfaces using your chosen
data access technology. When you are using Spring, working with interfaces is trivial, and you can easily
provide concrete implementations of your DAO interfaces to other components in your application.
In this section, we looked at some of the main design-related issues that are present when you are
building a data access layer for your application. In reality, much of the complexity in a data access layer
comes from implementation, not design. You can find more details on data access in Chapter 8 through
Chapter 11.
Designing the Service Layer
At this point in our application design discussion, we have a way of representing the data in our problem
domain so that we can manipulate it in code, and we have a way of storing this data in a database and
then getting it back out later. However, currently we are not doing much with this data. Unless your
application is especially simplistic, chances are some kind of logic needs to be implemented. Earlier, we
discussed cases where you should encapsulate logic inside your domain objects. In this section, we look
at providing a layer of service objects to provide a standard interface to the rest of your application logic.
Why Have a Service Layer
As with the question as to why you should have a data access layer, the answer to this question is plain
and simple once you have implemented a few applications without one. If you do not bring together all
the business logic in a single place, it ends up spread out through your presentation code, typically
resulting in lots of code duplication, not to mention creating code that lacks clearly defined boundaries
for responsibilities. Code duplication issues aside, failing to define clear boundaries between code with
different responsibilities often results in code that is difficult to trace and maintain, because it becomes
hard to pinpoint the location of a given function.
A well-defined service layer acts as a sort of gateway into your application, providing your
presentation code with a simple, unified way to get at business logic. A good service layer also serves as a
Search WWH :
