DAO и сервисный уровень с гибернатом

Question

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

В реализации DAO я могу написать всю логику CRUD для конкретной технологии и объекта (например, hibernate и User table), а на уровне сервиса мы используем DAO для всех операций с данными для объекта в DAO (например, getUser , loginUser и т. д.), это нормально?

Если это нормально, у меня есть простой вопрос, могу ли я обработать соединение с базой данных (или в случае спящего режима, сеанса и транзакции) в пределах уровня обслуживания, реализации DAO или нет?

Пример: у меня есть простой графический интерфейс с одной кнопкой (загрузка всего пользователя), а таблица будет содержать все Пользователь. Нажатие кнопки загрузит таблицу всем пользователям.

У меня есть объект HibernateDAO для пользователя (UserHibernateDAO), содержащий всю операцию CRUD и сервисный уровень UserService для некоторых конкретных операций с данными пользователя.

ServiceLayer:

public class UserService extends AbstractServiceLayer{ 

    private AbstractDAO dao; 

    public UserService(AbstractDAO dao){ 
    this.dao=dao; 
    } 

    public List<User> loadAllUsers(){ 
    return dao.findAll(); 
    } 

} 

В actionperformed Баттона:

private void buttonActionPerformed(ActionEvent evt) { 
    Transaction transaction=HibernateUtil.getSessionFactory().getCurrentSession().beginTransaction(); 
    List<User> users=userService.loadAllUsers(); 
    loadTableWithUsers(users); 
    transaction.commit(); 
} 

Является ли эта реализация нормально? Сессия и дескриптор транзакции находятся в правильном положении, или я должен поместить его в сервисный уровень? .. или, возможно, в дао?

EDIT1:

Если у меня есть UserDAO интерфейс и UserHibernateDAO, который реализует UserDAO, сервис слой не имеет никаких оснований существует, это не так? Becouse я могу иметь весь метод управления в «USER» в моем UserDAO и UserHibernateDAO реализует все эти методы спящей технологии ... тогда я мог бы иметь UserJdbcDAO, UserMysqlDAO и т.д ... ммм ...

edit2 :

private void buttonActionPerformed(ActionEvent evt) { 
    myBusinessMethod(); 
} 

private void myBusinessMethod(){ 
    Transaction transaction=HibernateUtil.getSessionFactory().getCurrentSession().beginTransaction(); 
    List<User> users=userService.loadAllUsers(); 
    loadTableWithUsers(users); 
    //some other useful operation before close session 
    transaction.commit(); 
} 

им не уверен, бизнес-метод представляет собой метод, как это?

Спасибо всем.

Answer 1

1. Вы обрабатываете транзакцию внутри своего метода actionPerformed(). Его явно поражение цели слоя DAO/Service
2. Ваш UserService принимает AbstractDAO, что означает какой-либо другой код может передать неправильную реализацию DAO к вашим UserService, что будет винт вещи

Теперь, несколько предложений.

1. Для этого можно посмотреть GenericDAO concept. Это может подойти вам.
2. Большую часть времени нам не нужны все эти слои, такие как Service, DAO и BusinessDelegate. Итак, задавайте себе вопрос, что любой из них действительно отвечает на некоторые ваши вопросы. Если нет, избавитесь от них.YAGNI
3. Избавьтесь от DAO полностью и обработайте свой Hibernate API как свой DAO. Обработать транзакцию базы данных в своих бизнес-методах. Вы можете, как прочитать эту question

[Изменено]

После правки мое третье предложение не имеют большого веса. Кстати, вы называете свои DAO следующим образом; UserJdbcDAO, UserMysqlDAO и т. Д. Ваше второе имя не имеет особого смысла, поскольку мы используем ORM только для того, чтобы избежать специфических DAO-запросов или запросов DB-поставщика. Это может начать иметь смысл, если ваш UserMysqlDAO extends UserJdbcDAO.