Как использовать DAO с hibernate / jpa?

Question

Если предположить, что структура DAO и взаимодействие компонентов описаны ниже, как следует использовать DAO с постоянными уровнями, такими как Hibernate и Toplink? Какие методы они должны / не должны содержать?

Будет ли плохой практикой переносить код из DAO непосредственно в службу?

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

public class BasicDao<T> {
 public List<T> list() { ... }
 public <T> retrieve() { ... }
 public void save() { ... }
 public void delete() { ... }
}

Шаблон взаимодействия компонентов -

сервис> DAO> модель

Answer 1

Мы обнаружили (как и другие), что было просто написать общий DAO в качестве тонкой прокладки поверх вызовов JPA.

Многие просто были на вершине JPA. Например, в начале у нас просто было:

public <T> T update(T object) {
    return em.merge(object);
}

Но преимущество наличия слоя в том, что ваш слой расширяемый, а EM - нет.

Позже мы добавили перегрузку:

public Thing update(Thing object) {
    // do magic thing processing
}

Итак, наш слой в основном не поврежден, но может обрабатывать пользовательские данные.

Например, позже, поскольку в ранних версиях JPA не было обработки Orphan, мы добавили это в наш бэкэнд-сервис.

Даже простой общий DAO имеет значение, просто как точка абстракции.

Нам просто не нужно было создавать по одному для каждой группы объектов (CustomerDAO, OrderDAO и т. Д.), Как в старые времена.

Answer 2

ИМХО, нет метода, который DAO "должен" содержать вообще. Он должен содержать именно те методы, которые нужны вашему приложению. Это может отличаться от модели к модели.

В Hibernate и JPA такие методы, как save и retrieve, являются "тривиальными" операциями, предоставляемыми менеджером сеанса / сущности, поэтому я не вижу особого смысла в их добавлении в DAO, кроме, возможно, изоляции сервисная / бизнес-логика из фактической персистентности реализации. Однако JPA уже сама по себе является изоляцией.

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