KachalovСделайте класс (возможно Bean) который будет выполнять действия с БД - это будет Model.

Истинно так. У меня это обычно класс типа Session Bean, который я обзываю Executor который содержит в себе все методы, которые выполняют нужные в приложении операции с базой данных - добваление / обновление / удаление / чтение. Обычно я создаю пул объектов этого класса. При активации объект Executor из пула берет соединение с БД (из другого отдельного пула), при пассивации соединение возвращает. В случае использования Hibernate или другого ORM при активации объект Executor содержит в себе ORM сессию, при активации сессию соединяет с БД (reconnect), при пассивации сессию закрывает. Все очень удобно и эффективно.

В терминологии ТимоН это есть не что иное, как его "DO объект, DAO каторый из БД или еще откуда нибудь берет данные, некий Service класс".

Пул таких объектов большого смысла не имеет, но уменьшает объем работы для GC. Кроме того, при количестве методов 200 и более в приличном приложении время создания объекта Executor становится соизмеримо со временем его доставания из пула, что в сочетании с экономией на GC уже придает пулу смысл. Тем более для Wев-приложения, где на каждый запрос, требующий Model, надо либо создать Executor, либо достать его из пула.

Этот подход у меня одинаков при использовании Struts и JSF.