QA@IT
«回答へ戻る

回答を投稿

私はテーブル単位でDAOを作成するようにし、サービス単位のDAOは作成しないようにしています。理由は下記です。
・サービス単位でDAOを作ると類似SQLが複数のDAOに存在するようになり、テーブル定義の変更による修正箇所が多くなりメンテナンス性が低下し、それに従い修正漏れによる品質低下のリスクがある。また、開発工数も余計にかかる。
・DAOのメソッドは1メソッド1SQL、業務ロジックやトランザクション処理は含まないというのを基本ルールすることで、DAOメソッドの共有利用率を高められる。
・トランザクション処理が必要な一連の処理はDAOではなく、DAOの呼び出し元のドメインクラス側に持たせ、トランザクション処理はそのドメインクラスを呼び出すサービスクラスで実行する(実際にはフレームワークに吸収してしまいますが)ことで、トランザクション単位が異なってもDAOメソッドが共有できる。
・SQLは基本的にトランザクションコミット時にバルク発行することでレスポンスを確保することができる(いつもHibernateを愛用しているので不整合も発生しません)。
・Joinや一部の項目のみ取得するような場合は、中心となるテーブルがあるはずなので、そのテーブルのDAOにメソッドを実装するというルールにすることで、どのDAOに実装するか迷うことは無い。

私の場合、ある程度複雑な業務ロジックがあり開発規模も数十人月以上の基幹システムの開発をすることが多いため、上記のような方針とすることでメンテナンス性、品質、生産性を確保するようにしています。小規模なシステムではちょっと重いアーキテクチャかもしれませんが・・・。

投稿者:もっくん

私はテーブル単位でDAOを作成するようにし、サービス単位のDAOは作成しないようにしています。理由は下記です。
・サービス単位でDAOを作ると類似SQLが複数のDAOに存在するようになり、テーブル定義の変更による修正箇所が多くなりメンテナンス性が低下し、それに従い修正漏れによる品質低下のリスクがある。また、開発工数も余計にかかる。
・DAOのメソッドは1メソッド1SQL、業務ロジックやトランザクション処理は含まないというのを基本ルールすることで、DAOメソッドの共有利用率を高められる。
・トランザクション処理が必要な一連の処理はDAOではなく、DAOの呼び出し元のドメインクラス側に持たせ、トランザクション処理はそのドメインクラスを呼び出すサービスクラスで実行する(実際にはフレームワークに吸収してしまいますが)ことで、トランザクション単位が異なってもDAOメソッドが共有できる。
・SQLは基本的にトランザクションコミット時にバルク発行することでレスポンスを確保することができる(いつもHibernateを愛用しているので不整合も発生しません)。
・Joinや一部の項目のみ取得するような場合は、中心となるテーブルがあるはずなので、そのテーブルのDAOにメソッドを実装するというルールにすることで、どのDAOに実装するか迷うことは無い。

私の場合、ある程度複雑な業務ロジックがあり開発規模も数十人月以上の基幹システムの開発をすることが多いため、上記のような方針とすることでメンテナンス性、品質、生産性を確保するようにしています。小規模なシステムではちょっと重いアーキテクチャかもしれませんが・・・。



投稿者:もっくん