web-dev-qa-db-ja.com

DAO＆BO（データアクセスレイヤー）-アーキテクチャ

私はウェブで見つけた例について少し混乱しています- spring＆hibernate （point 4. Model & BO & DAO）。モデル、DAO、およびBOクラス（+ DAOおよびBOインターフェース）があります。私が明確に理解していないのは、DAOとBOがまったく同じ機能を共有しているのに、なぜDAOとBOが異なるクラスに分かれているのかです（BOにDAOセッターがあるだけです）。

著者は、パターンが次のことを説明しているだけです：

レイヤーを明確に識別して、プロジェクト構造を混乱させないようにするのに役立ちます

しかし、私には過剰に設計されているようです（少なくともこの場合）。この例は非常に単純であることを知っていますが、このクラス分離は何に役立つでしょうか？誰かが例を提供できますか？

javadatabasedaolayer
17
ducin

彼らがBOと呼ぶものはビジネスサービスのようです。 DAOの仕事は、永続化関連のコード（データベースの挿入、更新、クエリ）を含めることです。

サービスはトランザクションの境界を定め、ビジネスロジックを含み、通常、このロジックを実装するために1つまたは複数のDAOを使用します。一部のユースケースでは、サービスはDAOに委任するだけです。その他の場合は、1つまたは複数の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
}
32
JB Nizet