DAO и сервисный уровень с гибернацией - PullRequest
4 голосов
/ 27 октября 2010

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

В реализации DAO я могу написать всю логику CRUD для конкретной технологии и объекта (например, Hibernate)и пользовательская таблица), а на уровне сервиса мы используем 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();
    }

}

В действии выполнено для кнопки:

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

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

EDIT1:

Если у меня есть интерфейс UserDAO и UserHibernateDAO, который реализует UserDAO, сервисный уровень не имеет никаких оснований для существования, не 'правда?Поскольку у меня может быть весь метод для управления «ПОЛЬЗОВАТЕЛЕМ» внутри моего UserDAO, а UserHibernateDAO реализует все эти методы для технологии гибернации ... тогда я мог бы иметь UserJdbcDAO, UserMysqlDAO и т.д ... ммм ...

РЕДАКТИРОВАТЬ2:

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();
}

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

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

1 Ответ

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

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

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

[Изменено]

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

...