DAOの作成単位について

MVCでWebアプリを作成していると、ほぼ必ずDAOを作成することになると思いますが、DAOの作成単位にいつも悩みます。今までの経験によると大きく二つ「テーブル単位」か「サービス（ビジネスロジック）単位」にDAOを作成している方が多いようですが、それぞれの作成単位によってメリットデメリットがあると思います。この二つ以外にもDAOの作成単位があるかもしれませんが、どちらがよいのか皆さんの意見を聞かせていただきたいです。

１．テーブル単位
【メリット】
　・同じ処理(SQL)が複数DAOに分散しない
【デメリット】
　・複数テーブル情報をまとめてSELECTするような場合、どのテーブルDAOに実装するか迷う。
　・トランザクション処理が必要な一連の処理を記述する場合、テーブル単位では記述できない。

２．サービス（ビジネスロジック）単位
【メリット】
　・トランザクション処理が必要な一連の処理を記述する場合、違和感が無い。
【デメリット】
　・複数のサービスDAOで同じ処理(SQL)が書かれる可能性がある。

No.3 回答者： djodjo 回答日時： 2006/04/17 21:40

よくやっていることは・・・

以下の単位でDAOを作成します。
１．テーブル単位を操作するDAO
１件しか帰ってこない検索とInsert,Update,Delete

２．テーブル連結する単位
こっちは１クラス１メソッドで実装
　複数テーブル連結する場合です。

トランザクションは、DAOを呼び出す上位のクラスを用意してそこで行っています。

「SQLを生成して実行する」ことと「rollbackやcomitの管理」は別々に行うようにしてます。

なので、ビジネスロジック単位というDAOは存在しません。
単一表へのアクセスは１表しか管理しない共通のトラン管理クラスを用意しています。

BL->トラン管理->DAO->DB
って順番です。

この回答への補足

皆さん、様々なご意見ありがとうございました。
ここでもう一点、皆さんにご意見を聞かせていただきたいのですが、
トランザクション処理を含むビジネスロジックをどこに書かれているのでしょうか？
DIやAOPは使わない開発の場合です。

１．ドメインクラスに記述
【メリット】
オブジェクト指向としてはドメインクラスにビジネスロジックを持たせることが正しい。
【デメリット】
POJOとして考えた場合、データベースアクセスが入るのは思想に反している。単体テストが簡単にできない。

２．ビジネスロジッククラスに記述
【メリット】
設計やクラス階層がわかりやすく、他のMVCクラスがビジネスロジッククラス以外とは関連が無い状態になる。
【デメリット】
オブジェクト指向的な設計ではない。

補足日時：2006/04/19 11:14

No.2 回答者： kazsharp 回答日時： 2006/04/14 16:09

この方法がいいかどうかわかりませんが、以前に行った方法として、

・（ほぼ）テーブル単位のDAO作成
・サービス単位のDAO作成
・サービス単位のDAOからテーブル単位のDAOを呼び出し

のように設計しました。
「DAO」に対する実装が質問者さんとズレがあるかもしれませんが、無駄なく違和感なく実装できました。

参考までに

No.1 回答者： arakororin 回答日時： 2006/04/14 01:55

DAOってはっきりいって「オブジェクト」として捉えた場合、どうでもいい単位のクラスだと思います。

理由はプロパティをもつ必要が無いため「オブジェクト」である必要は無いからです。

なので、全部static変数でインスタンス化しないクラスでもかまわないし、あらゆるメソッドを1つにまとめてDAOにしてもかまわないでしょう。1つのメソッドにつき1クラスにしてしまってもいいかもしれません(これはやったことがあります。おすすめできませんが)。その意味では、「１．テーブル単位」でも「２．サービス（ビジネスロジック）単位」でもその他でも何でもいいと思います。


しかし、全体のつくりの整合性を保つために、他のクラスの分割と同様のポリシーで分割すべきでしょう。
オブジェクト指向っぽく機能や役割単位で分割するのか、
オブジェクト指向無視であくまでもリクエスト単位で分割するのか。

前者なら「１．テーブル単位」
後者なら「２．サービス（ビジネスロジック）単位」

と言うことになると思います。


「１．テーブル単位」のデメリットの1つ目は、複数のテーブルにアクセスする場合であっても、通常主となるテーブルがあるはずです。そちらに含めるべきでしょう。

また、マスタ系のテーブルで参照しかしないメソッドを集めて1つのクラスにしてもいいとおもいます。おおむねテーブル単位、特殊なものはその役割に着目した単位でまとめる、と言うのがいいのではないかと思います。


あと、「１．テーブル単位」のデメリットの2番目ですが、そのようなデメリットが生じてしまう記述の仕方に問題があるように思えます。そもそもトランザクションをDAOの中で完結させると言う記述には無理があると思います。テーブルアクセスの間にBLの処理が入ることもありえ、そのようなケースに対応できないからです。

無理にDAOでトランザクションを行おうとすれば、自然と同じデータアクセス処理を何度も記述しなければならない構成になってしまうでしょう。

DAOでは純粋にデータアクセスのみの記述にとどめ、そのコントロールはBLなどで行うべきだと思います、というかアスペクトできれいに1箇所にまとめるといいと思います。

なんにせよ、テーブル単位でDAOを作成するとトランザクション処理ができないと言うことはありません(それができないような記述にしてしまうことも可能ですが…)。