что писать в классе userDAO в java spring hibernate

Question

У меня есть класс домена User со свойствами и получателями

Тогда у меня есть класс userService, который включает в себя все функции, такие как

addUser DeleteUser

public void register(User person) {
      logger.debug("Adding new Registration");
      Session session = sessionFactory.getCurrentSession();
      session.save(person);
     }

Я использую hibernate.

Моя система работает нормально.но я запутался, где стоит UserDAO в моем случае.Нужно ли мне это или что мне нужно написать там

Answer 1

Ничто так не заставляет вас иметь слой DAO.

UI <-> Service <-> DAO <-> persistence

Код вашего уровня сеанса - это то, что обычно входит в уровень DAO. То есть небольшие (почти атомарные) операции, такие как сохранение, удаление и т. д.

Сервисный уровень предназначен для изоляции бизнес-логики, которая была бы неудобной на простом уровне хранения. Например, если вы хотите работать с несколькими экземплярами Person одновременно или использовать какую-то очень специфическую бизнес-логику перед сохранением объекта. Другое распространенное использование с RDBM - это управление транзакциями на уровне обслуживания, координируя, возможно, несколько запросов DAO в транзакции.

Во многих простых приложениях уровень обслуживания несколько бессмыслен. Он просто передает операции, как и выше, от UI до DAO - никакой логики не добавлено. В этих случаях я лично не обязательно создавал бы слой DAO, сохранял бы хранилище в сервисе, но реорганизовывал его в тот самый момент, когда он вырастает за пределы простого уровня персистентности.

Другим аспектом является модульное тестирование. Простой слой DAO может быть легко смоделирован, что является аргументом для разделения бизнес-логики и постоянства.

Answer 2

DAO обычно содержат операции сохранения данных.В ORDBMS это в основном операции CRUD (создание, чтение, обновление, удаление).DAO обозначает объект доступа к данным. Взгляните на общий дао

Несмотря на то, что уровень обслуживания не содержит много бизнес-логики, рекомендуется отделить уровень доступа к данным от уровня обслуживания.Это обычная дилемма, зачем мне нужен еще один слой, если мой код достаточно прост, чтобы поместиться в один слой. Направление и рефакторинг

По сути, если вы разделяете задачи и обязанности, это помогает сделать код более адаптируемым к изменениям.Я надеюсь, что это отвечает на оба вопроса (что и почему)

Answer 3

Я использовал этот подход на своей последней работе (особенно в своем собственном ответе, Александр) и обнаружил, что DAO действительно увязла в логике и отношениях, которые должны были быть в самом пользователе.Я согласен с Мартином, вам действительно не нужен DAO.Во всяком случае, используйте универсальную типобезопасную оболочку SessionFactory.

  public class SessionFactoryWrapper{

       private SessionFactory sessionFactory;

       public <T extends ObjectWithID> T load(long id, Class<T> clazz){
             return (T) sessionFactory.getCurrentSession().load(clazz, id);
       }

       //... etc...
  }

Это заставляет вас абстрактно взаимодействовать со своим сеансом и работать с кодом уровня модели в вашем домене, что обеспечивает чистоту кода.

Answer 4

Как уже указывалось здесь, совсем не обязательно, что вам нужен слой DAO. Если ваш сервисный уровень не содержит много логики, вы можете найти приемлемым поместить туда логику DB / Hibernate. Чего вы не хотите, так это помещать свою логику DAO на уровень пользовательского интерфейса, поскольку это делает модульное тестирование более сложным и запутанным.

Другим решением является поиск библиотеки, которая облегчает написание слоя DAO. Hades - это такая библиотека, которая во многих случаях предоставляет вам все необходимые методы dao бесплатно. С Hades ваш DAO-код будет выглядеть так:

public interface UserDao extends GenericDao<User, Long> {
}

Затем вы получаете такие методы, как постоянство, поиск (также с подкачкой), подсчет, удаление и т. Д.