definition of what your application can actually perform and what logic is available to be presented to
the user.
A significant drawback of not having a service layer comes about when you decide to have two kinds
of user interface for the same logic. Perhaps you built a web application, but now you want to provide a
desktop-based application for users who use the application often. If your business logic code is
embedded within your web presentation code, you are going to have to either refactor the code out of
the presentation layer, which requires a significant amount of effort in rework and testing, or simply
reproduce the business logic code again, this time embedded within the code of the rich client (e.g.,
Swing, RCP, and so on).
Nowadays, besides various frontends, your business services will also probably be accessible from
other systems. For example, your application may provide real-time stock quote information to some
other third-party business partners. Mostly likely, you will need to support the access by those partners to
your real-time data via web services (e.g., web services, RESTful-WS, and so on). Also, when processing
data in batches (e.g., from a file), the data manipulation logic should not have much difference from that
of a user entering the data via the web interface. A centralized service layer as the entry point for data
coming from all possible sources becomes a critical part in keeping your application maintainable.
Designing Business Interfaces
As with most components in your application, you should start by defining a set of interfaces for the
service objects in your application. Any code that interacts with your service layer should do so through
these interfaces. For components that Spring manages, you can supply implementations using DI. If you
have to support components that Spring does not manage, you may want to supply a simple Factory
class to allow for implementation lookup.
Service Layer Dependencies
As with all the interfaces we have talked about, you should avoid defining dependencies in the interfaces
of your service objects. The service object should be completely implementation-independent. A well-
defined service object interface has only those methods that serve business functions. Avoid exposing
types from your data access layer through your service objects. Your service objects should insulate the
presentation code from the underlying data access layer completely. For example, one of your service
objects might access all its data using web services or via a JMS queue. A good way to ensure that your
service object interface is as accessible as possible is to ensure that return and argument types do not
couple the presentation code to anything other than the DOM. You are going to be passing domain
objects through all the layers of your application, but other components such as DAOs should stay well
within their own layer.
Service Object Granularity
When designing the objects required in the service layer, try to relate them with the possible use cases in
the business requirements.
A common practice is to group the logic that manipulates highly related domain objects into the
same service object interface. For example, in the SpringBlog application, the design of the service layer
is composed of the interfaces listed in Table 12-1.
Search WWH :
