Which design pattern is better to work with Controllers/Services/DAOs

Question

During my career I saw few different designs, how to work with DAO, Service, Controller layers. I want to ask about two, which are similar but have few differences. First design creates visible barrier between layers. Controllers always use services and only services. Services can use other services or DAOs. Controllers can't use any DAO directly. This design is clear, but has big disadvantage for me: we always have to create method in service for each method in DAO. But in a lot of cases Service methods invoke only DAOs methods and anything else.

For example: We have UserDao

class UserDao {
    public List<User> findByName(String name) { ... }
    public List<User> findByLastName(String name) { ... }
    public List<User> findOlderThan(int age) { ... }

    ......
}

All above methods are used by Controllers. What we should do in our case? Create similar methods in UserService:

class UserService {
    public List<User> findByName(String name) { return userDao.findByName(name); }
    public List<User> findByLastName(String name) { return userDao.findByLastName(name); }
    public List<User> findOlderThan(int age) { return userDao.findOlderThan(age); }

    ......
}

For me this is additional unnecessary layer for read-only methods.

In second design we do not have a problem with this because we can use DAOs directly in Controllers. In this design we have a rule: if we want to retrieve a data from "data store" we can use DAO in any layer, if we want to make some changes in "data store" we have to use service methods.

What do you think, guys, about these designs? Which is better? Which I should use in my projects and which should be forgotten? Could you share with me yours experience in this sphere?

Answer 1

Services, in MVC and MVC-inspired design patterns are the "top part" of the model layer. It's how presentation layer interacts with domain business logic (also, the "reading" part should be done by view instances, actually).

In such structure the services act as a barrier, that isolates presentation layer and gives you additional freedom in altering the internal structure of model later.

Another thing that you have to keep in mind is that there are more structures then just DAOs that services interact with. First of all there are domain objects (business objects, model objects) which encapsulate the different business rules that relate to one particular entity. Then you also can have data mappers, which abstract the storage logic instead of DAOs. Or DAOs that translate information between mappers and domain objects. In larger scale application would would also have unit(s) of work. In smaller scale you would be fine with some active record instances.

You could say that model layer contains three main groups of structure where the implement separate aspects of model: domain, storage and application logic.

The application logic is the interaction between storage structures domain objects. That is what services are responsible for.

If you expose DAO, your model layer starts leak in the presentation. Controller should have no idea about what structures are used, and when they are persisted.