На основании статьи Не повторяйте DAO , мы использовали эту технику много лет. Мы всегда боролись с проблемами с нашими моделями после того, как поняли, что допустили большую ошибку.
При использовании инструмента ORM, такого как Hibernate или JPA, вам не придется отдельно рассматривать DAO и уровень службы. Вы можете использовать EntityManager из своих классов обслуживания, поскольку вы знаете жизненный цикл транзакций и логику ваших классов сущностей там.
Вы экономите минуту, если звоните myDao.saveEntity
вместо простого entityManager.saveEntity
? Нет. У вас будет ненужный класс dao, который больше ничего не делает, но будет оберткой вокруг EntityManager. Не бойтесь писать выбор в ваших классах обслуживания с помощью EntityManager (или сеанса в спящем режиме).
Еще одно замечание: вы должны определить границы вашего сервисного уровня и не позволять программистам возвращать или ждать классов Entity. Программисты уровня UI или WS вообще не должны знать о классах сущностей только о DTO. У сущностных объектов есть жизненные циклы, о которых большинство программистов не знают. У вас будут действительно серьезные проблемы, если вы сохраните объект сущности в данных сеанса и попытаетесь обновить его обратно в базу данных через несколько секунд или часов. Ну, вы можете этого не делать, но программист пользовательского интерфейса, который знает типы параметров и типы возвращаемых данных вашего уровня обслуживания, сделает только несколько строк кода.