DAO & BO (warstwa dostępu do danych) - architektura

Question

Jestem nieco zdezorientowany na przykład znaleziony w Internecie - spring & hibernate (punkt 4. Model & BO & DAO). Istnieją klasy Model, DAO i BO (+ interfejsy DAO i BO). To, czego nie rozumiem, to dlaczego DAO i BO są podzielone na różne klasy, jeśli mają dokładnie te same funkcje (tylko różnica polega na tym, że BO ma ustawnik DAO).

Autor wyjaśnia jedynie, że wzór:

jest przydatna do identyfikacji warstwy wyraźnie uniknąć bałagan strukturę projektu

ale wydaje ponad zaprojektowane do mnie (co najmniej w tym przypadku). Wiem, że ten przykład jest bardzo prosty, ale do czego mogłaby się przydać ta separacja klas? Czy ktoś może podać przykład?

Answer 1

To, co nazywają BO, wydaje się być usługą biznesową. Zadaniem DAO jest zawarcie kodu związanego z utrwalaniem: wstawianie, aktualizowanie, odpytywanie bazy danych.

Usługi wyznaczają transakcje, zawierają logikę biznesową i zwykle używają jednego lub kilku DAO do wdrożenia tej logiki. W niektórych przypadkach usługa deleguje tylko do DAO. Dla innych wywołuje kilka metod jednego lub kilku DAO.

Klasycznym przykładem jest transfer pieniędzy:

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 
}