Почему помещенный уровень DAO по слою персистентности (как JDO или В спящем режиме),

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

1. DAO
2. Service
3. UICode

с POJO, передаваемыми сверху вниз. внизу.

Вы отметили несколько моментов. Но я, тем не менее, использую уровень Dao, и вот почему:

1. Доступ к базе данных - это вызов удаленной системы . Во всех таких случаях (также веб-сервис, ajax и т. Д.) Степень детализации взаимодействия должна быть достаточно большой. Многие крошечные вызовы убивают производительность. Эта потребность в производительности часто требует другого взгляда на систему или уровень (здесь уровень Dao).

2. Иногда ваша операция сохранения заключается только в загрузке / сохранении / удалении объекта. За это может отвечать один уникальный Дао (или суперкласс; рассмотрим Generics), поэтому вам не нужно кодировать эти методы снова и снова.
   Но часто у вас также есть особые потребности, такие как выполнение определенного запроса, который не создается автоматически ORM . Там вы кодируете свою конкретную потребность с помощью определенного метода Дао (часто возможно повторное использование).
   Наличие регулярных и конкретных потребностей на одном уровне позволяет повторно использовать (например, перехват может гарантировать, что соединение с базой данных открыто / зафиксировано, когда это необходимо).

Одно слово: транзакции

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

Поэтому я пишу DAO. Возьмите этот псевдокод, использующий транзакции Spring и спящий режим:

отредактирован для удаления HQL, который так оскорблял @Roger, но не имел отношения к делу

@Transactional
public void doUnitOfWork() {
  // some persistence operation here
  // some other persistence operation here
}

Моя бизнес-логика вызывает doUnitOfWork (), которая начинает транзакцию, выполняет обе операции сохранения, а затем совершает. Он не знает и не заботится о транзакции или о том, какие операции выполняются.

Кроме того, если DAO реализует интерфейс с методом doUnitOfWork (),

При использовании инструмента ORM, такого как JDO или JPA, DAO являются анти -шаблон. В этом случае создание «уровня доступа к данным» совершенно не нужно и только добавит дополнительный код и усложнит кодовую базу, что усложнит ее разработку и сопровождение.

Основываясь на моем предыдущем опыте, я бы порекомендовал использовать простой статический фасад, например Persistence , чтобы обеспечить простой в использовании высокоуровневый API для операций, связанных с сохранением состояния.

Затем , вы можете использовать статический импорт, чтобы получить легкий доступ к этим методам везде, где они могут быть полезны. Например, у вас может быть такой код:

    List<Book> cheapBooks = 
        find("select b from Book where b.price < ?", lowPriceForBooks);
    ...
    Book b = new Book(...);
    persist(b);
    ...
    Book existingBook = load(Book.class, bookId);
    remove(existingBook);
    ...

Приведенный выше код максимально прост и прост, и его можно легко протестировать на единицу.