MVCでWebアプリを作成していると、ほぼ必ずDAOを作成することになると思いますが、DAOの作成単位にいつも悩みます。今までの経験によると大きく二つ「テーブル単位」か「サービス(ビジネスロジック)単位」にDAOを作成している方が多いようですが、それぞれの作成単位によってメリットデメリットがあると思います。この二つ以外にもDAOの作成単位があるかもしれませんが、どちらがよいのか皆さんの意見を聞かせていただきたいです。
1.テーブル単位
【メリット】
・同じ処理(SQL)が複数DAOに分散しない
【デメリット】
・複数テーブル情報をまとめてSELECTするような場合、どのテーブルDAOに実装するか迷う。
・トランザクション処理が必要な一連の処理を記述する場合、テーブル単位では記述できない。
2.サービス(ビジネスロジック)単位
【メリット】
・トランザクション処理が必要な一連の処理を記述する場合、違和感が無い。
【デメリット】
・複数のサービスDAOで同じ処理(SQL)が書かれる可能性がある。
A 回答 (3件)
- 最新から表示
- 回答順に表示
No.3
- 回答日時:
よくやっていることは・・・
以下の単位でDAOを作成します。
1.テーブル単位を操作するDAO
1件しか帰ってこない検索とInsert,Update,Delete
2.テーブル連結する単位
こっちは1クラス1メソッドで実装
複数テーブル連結する場合です。
トランザクションは、DAOを呼び出す上位のクラスを用意してそこで行っています。
「SQLを生成して実行する」ことと「rollbackやcomitの管理」は別々に行うようにしてます。
なので、ビジネスロジック単位というDAOは存在しません。
単一表へのアクセスは1表しか管理しない共通のトラン管理クラスを用意しています。
BL->トラン管理->DAO->DB
って順番です。
この回答への補足
皆さん、様々なご意見ありがとうございました。
ここでもう一点、皆さんにご意見を聞かせていただきたいのですが、
トランザクション処理を含むビジネスロジックをどこに書かれているのでしょうか?
DIやAOPは使わない開発の場合です。
1.ドメインクラスに記述
【メリット】
オブジェクト指向としてはドメインクラスにビジネスロジックを持たせることが正しい。
【デメリット】
POJOとして考えた場合、データベースアクセスが入るのは思想に反している。単体テストが簡単にできない。
2.ビジネスロジッククラスに記述
【メリット】
設計やクラス階層がわかりやすく、他のMVCクラスがビジネスロジッククラス以外とは関連が無い状態になる。
【デメリット】
オブジェクト指向的な設計ではない。
No.2
- 回答日時:
この方法がいいかどうかわかりませんが、以前に行った方法として、
・(ほぼ)テーブル単位のDAO作成
・サービス単位のDAO作成
・サービス単位のDAOからテーブル単位のDAOを呼び出し
のように設計しました。
「DAO」に対する実装が質問者さんとズレがあるかもしれませんが、無駄なく違和感なく実装できました。
参考までに
No.1
- 回答日時:
DAOってはっきりいって「オブジェクト」として捉えた場合、どうでもいい単位のクラスだと思います。
理由はプロパティをもつ必要が無いため「オブジェクト」である必要は無いからです。なので、全部static変数でインスタンス化しないクラスでもかまわないし、あらゆるメソッドを1つにまとめてDAOにしてもかまわないでしょう。1つのメソッドにつき1クラスにしてしまってもいいかもしれません(これはやったことがあります。おすすめできませんが)。その意味では、「1.テーブル単位」でも「2.サービス(ビジネスロジック)単位」でもその他でも何でもいいと思います。
しかし、全体のつくりの整合性を保つために、他のクラスの分割と同様のポリシーで分割すべきでしょう。
オブジェクト指向っぽく機能や役割単位で分割するのか、
オブジェクト指向無視であくまでもリクエスト単位で分割するのか。
前者なら「1.テーブル単位」
後者なら「2.サービス(ビジネスロジック)単位」
と言うことになると思います。
「1.テーブル単位」のデメリットの1つ目は、複数のテーブルにアクセスする場合であっても、通常主となるテーブルがあるはずです。そちらに含めるべきでしょう。
また、マスタ系のテーブルで参照しかしないメソッドを集めて1つのクラスにしてもいいとおもいます。おおむねテーブル単位、特殊なものはその役割に着目した単位でまとめる、と言うのがいいのではないかと思います。
あと、「1.テーブル単位」のデメリットの2番目ですが、そのようなデメリットが生じてしまう記述の仕方に問題があるように思えます。そもそもトランザクションをDAOの中で完結させると言う記述には無理があると思います。テーブルアクセスの間にBLの処理が入ることもありえ、そのようなケースに対応できないからです。
無理にDAOでトランザクションを行おうとすれば、自然と同じデータアクセス処理を何度も記述しなければならない構成になってしまうでしょう。
DAOでは純粋にデータアクセスのみの記述にとどめ、そのコントロールはBLなどで行うべきだと思います、というかアスペクトできれいに1箇所にまとめるといいと思います。
なんにせよ、テーブル単位でDAOを作成するとトランザクション処理ができないと言うことはありません(それができないような記述にしてしまうことも可能ですが…)。
お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!
関連するカテゴリからQ&Aを探す
おすすめ情報
- ・漫画をレンタルでお得に読める!
- ・人生のプチ美学を教えてください!!
- ・10秒目をつむったら…
- ・あなたの習慣について教えてください!!
- ・牛、豚、鶏、どれか一つ食べられなくなるとしたら?
- ・【大喜利】【投稿~9/18】 おとぎ話『桃太郎』の知られざるエピソード
- ・街中で見かけて「グッときた人」の思い出
- ・「一気に最後まで読んだ」本、教えて下さい!
- ・幼稚園時代「何組」でしたか?
- ・激凹みから立ち直る方法
- ・1つだけ過去を変えられるとしたら?
- ・【あるあるbot連動企画】あるあるbotに投稿したけど採用されなかったあるある募集
- ・【あるあるbot連動企画】フォロワー20万人のアカウントであなたのあるあるを披露してみませんか?
- ・映画のエンドロール観る派?観ない派?
- ・海外旅行から帰ってきたら、まず何を食べる?
- ・誕生日にもらった意外なもの
- ・天使と悪魔選手権
- ・ちょっと先の未来クイズ第2問
- ・【大喜利】【投稿~9/7】 ロボットの住む世界で流行ってる罰ゲームとは?
- ・推しミネラルウォーターはありますか?
- ・都道府県穴埋めゲーム
- ・この人頭いいなと思ったエピソード
- ・準・究極の選択
デイリーランキングこのカテゴリの人気デイリーQ&Aランキング
-
SQLを発行とは?クエリの作成と...
-
『列名 '担当者CD' があいま...
-
【ADO】「Execute」を使うと...
-
CSVファイルのエクスポートでソ...
-
VBとアクセスでSQL文に変...
-
COBOLのINVALID KEYが理解でき...
-
Accessで別mdbのテーブルをコピー
-
ワークテーブルの作成について
-
ロケールに対応するストリング...
-
手動または分散トランザクショ...
-
ExcelVBAからAccessMDB内のテー...
-
他のMDBのテーブルに追加したい
-
(泣)VBscriptでinnerhtmlを使...
-
DBFlute でシーケンス値取得
-
★クリスタルレポートの元になる...
-
HTMLのテーブルの行数が多くな...
-
オラクルデータベースへの更新方法
-
DataGridViewに複数テーブルの...
-
VBでコンボボックスとテキスト...
-
DataGridの中身をDataSetにテー...
マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング
-
『列名 '担当者CD' があいま...
-
SQLを発行とは?クエリの作成と...
-
VBとアクセスでSQL文に変...
-
Accessで別mdbのテーブルをコピー
-
手動または分散トランザクショ...
-
エクセルのテーブルを解除する...
-
CSVファイルのエクスポートでソ...
-
AccessからExcelへエクスポート...
-
HTMLのテーブルの行数が多くな...
-
ACCESS2010 実行時エラー 2766
-
ExcelVBAからAccessMDB内のテー...
-
Excel複数シートをaccessへ一括...
-
DataGridViewに複数テーブルの...
-
他のMDBのテーブルに追加したい
-
ワークテーブルの作成について
-
★クリスタルレポートの元になる...
-
COBOLのINVALID KEYが理解でき...
-
VBでコンボボックスとテキスト...
-
VB.NETでのAccessテーブルリンク
-
Accessのフォームでリス...
おすすめ情報