У меня три слоя:

dao
service
web

В слое dao находится ClientDAO

Если сервлет в web слое делает что-то простое, например кладет в request список клиентов, то ShowClientListController сразу использует ClientDAO.loadAllClients();

Если же делает что-то сложное, то использует к примеру AccountService, который в свою очередь использует dao слой.

Иногда случается так, что нужно из слоя бизнес-логики (в моем случае service) напрямую обратится к hibernate session. Думаю, в этом ничего плохого нет.

VetalСпасибо всем!
То-есть, вы предлагаете использовать паттерн DAO ВСЕГДА при более-менее больших программных системах?

Использовать dao вполне удобно для reuse кода. Когда нужно очередной раз выгрести к примеру клиента по id, вспоминается, что есть класс, который скорее всего это может сделать.

2 Vetal

Предположим, что ты передал проект другому программисту, либо с ростом системы просто забыл что когда-то писал метод ClientMapper.minusDollars(Integer myClientId, Double dollars); и тебе опять необходимо снять c клиента dollars денег.

Вспоминаем... ага, что-то подобное в прошлом делали.... хмм был же какой-то метод снимающий деньги с клиента...

Не очевидно, что этот метод должен принадлежать dao классу ClientMapper(СlientDAO).

Имхо в классе ClientMapper(ClientDAO) надо оставить функциональность, отвечающую за выгребание и сохранение объектов Client, а бизнес логику реализовывать в других классах, более подходящих по названию и функциональности.

Не претендую на правильность подхода, но это работает и не дает запутаться, когда кода довольно много.