DAO & BO (уровень доступа к данным) - архитектура

Я немного запутался в примере, найденном в Интернете - spring и hibernate (point 4. Model & BO & DAO). Существуют классы Model, DAO и BO (+ интерфейсы DAO и BO). То, что я не совсем понимаю, - это то, почему DAO и BO разделены на разные классы, если они имеют точно такие же функциональные возможности (только разница в том, что BO имеет средство DAO).

Автор объясняет только, что шаблон:

полезно четко идентифицировать слой, чтобы избежать беспорядка структуры проекта.

но мне кажется, что он слишком сконструирован для меня (по крайней мере, в этом случае). Я знаю, что этот пример очень прост, но зачем это разделение классов полезно? Может ли кто-нибудь привести пример?

ОТВЕТЫ

Ответ 1

То, что они называют BO, похоже, является бизнес-сервисом. Задача DAO состоит в том, чтобы содержать код, связанный с постоянством: вставка, обновление, запрос к базе данных.

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

Классический пример - услуга перевода денег:

public void transferMoney(Long sourceAccountId, Long targetAccountId, BigDecimal amount) {
    Account source = accountDAO.getById(sourceAccountId);
    Account target = accountDAO.getById(targetAccountId);
    if (source.getBalance().compareTo(amount) < 0) {
        throw new NotEnoughMoneyException();
    }
    source.decrementBalance(amount);
    target.incrementBalance(amount);
    auditDAO.insertTransaction(sourceAccountId, targetAccountId, amount);
    // other business logic
}