Responsibilities and use of Service and DAO Layers

It is a good idea to have those two layers when your business logic is more complex than your data logic. The service layer implements the business logic. In most cases, this layer has to perform more operations than just calling a method from a DAO object. And if you're thinking of making your application bigger, this is probably the best solution.

Imagine you want to include a City entity and create a relationship between People and City. Here is an example:

@Transactionalpublic class PeopleService {    ....    private PeopleDAO pDAO;    private CityDAO cDAO;    ...    public void createPerson(String name, String city)     throws PeopleServiceException {        Person p = new Person();        p.setName(name);        City c = cDAO.getCityByName(city);        if (c == null) throw new ServiceException(city + " doesn't exist!");        if (c.isFull()) throw new ServiceException(city + " is full!");        c.addPeople(p);        sess().save(p);        sess().save(c);    }    ...}

In this example, you can implement more complex validations, like checking the consistency of the data. And PersonDAO has not been modified.

Another example:

DAO and Service layers with Spring

Definition of Service layer pattern

If your application will grow with new and changing requirements you are very well served with having distinct layers for those TWO DISTINCT ASPECTS (persistence->DAO, business use case -> services) of your software.

One aspect is your persistence model with its relations, validations, transactions and many access patterns.

The services are driven by the business use cases which have a very different granularity. In the beginning you may have very simple services which don't do much more than calling DAOs to hand over data they received from, let's say, a web page. But this is likely to change over time and services will grow into small networks of collaborating objects that do a lot more to serve the business use case. If you don't use DAOs then

• your services will contain code that deals with querying objects, transaction handling, validation, all of which has nothing to do with real business requirements
• service code will look messy and it will be difficult to find out what parts of the code are actually business related
• if you then change the persistence model you might end up changing many services

Also you can not easily unit test your persistence model but write tests only on the service layer. Do not forget that decoupling and encapsulation are important techniques to minimize the impact of change.

When done right, having a DAO layer will not introduce much implementation overhead so there is not much extra cost in having it. It will soon pay off and you will be very glad to have this dedicated layer.

Check out this article: http://codeblock.engio.net/?p=180. It also comes with a full implementation hosted on github