データベース系アプリケーションで、データや処理をどこまでクラス化する？

投票結果総投票数：34
1.教科書どおり	20票	58.82%
2.GUIや業務ロジックのみ	1票	2.94%
3.全然意識しない	13票	38.24%
投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。投票結果の正当性や公平性について、＠ITは一切保証も関与もいたしません。

投稿者

投稿内容

maru: ぬし; 会議室デビュー日: 2003/01/27; 投稿数: 412

投稿日時: 2004-07-10 17:08

こんにちは。

いまさらこんな質問も恥ずかしいのですが・・・。
ここ1.5年ほどJavaで非データベース系アプリ（画像処理ソフト）を作っていました。
当然、オブジェクト指向としての作りで作っており、画面構成やデータの処理などオブジェクト
化したことでかなりソースコードがコンパクトになったり、保守性が増し、オブジェクト指向
の恩恵を受けたのを実感しました。

で、今度はデータベース系のアプリをVB.NETで作ることになりました。データベースその
ものはVBで6年ほどやっているので全然問題ないのですが、VB.NETでオブジェクト指向とし
て開発する場合、どこまでをクラス化するのかで今頭を悩ませてます。

GUIなど画面構成やそのコントロール（制御）に関しては、どのようにクラス化するのかは
イメージが浮かぶのですが、データベースのデータやビジネスロジックに関してどこま
でクラス化すべきなのでしょうか？

UMLを使ったデータベース系アプリ開発の入門書などを読むと、単純にテーブル1つが1つの
クラス（例えば、顧客テーブル＝顧客クラス、見積テーブル＝見積クラスなど）に対応する
イメージが浮かんでしまいます。
そのクラスが1つのテーブルに対応して、データのデータベースへの追加や更新、削除はその
クラスのメソッドで行うようなイメージです。

しかし実際には、顧客テーブルでも画面によっては一部の列しか呼び出す必要もなかったり、
1回のSQLの呼び出しで複数テーブルやマスタを結合して読み込んだり、複数テーブルで１トラン
ザクションだったり、１クラス＝１テーブルの設計では苦しいような気もします。

理想は教科書どおり、すべてのデータ、ロジックをすべてオブジェクト指向を意識してクラス化
すべきかもしれませんが、結局、オブジェクト指向といっても、データベース系アプリは
GUIやその制御、汎用的な業務ロジックをクラス化し、データベースのデータそのものまでは
クラス化しないほうがよさそうな気もします。

オブジェクト指向系言語でデータベース系アプリを開発する場合、実際のところみなさんは
どのレベルまでオブジェクト指向を意識してクラス設計をしますか？

1.教科書どおりすべてのデータと処理をクラス化
2.GUI系や業務ロジックのみで業務データまではクラス化しない
3.全然オブジェクト指向は意識しない

ぽん: 大ベテラン; 会議室デビュー日: 2003/05/13; 投稿数: 157

投稿日時: 2004-07-10 19:46

引用:

maruさんの書き込み (2004-07-10 17:08) より:

しかし実際には、顧客テーブルでも画面によっては一部の列しか呼び出す必要もなかったり、
1回のSQLの呼び出しで複数テーブルやマスタを結合して読み込んだり、複数テーブルで１トラン
ザクションだったり、１クラス＝１テーブルの設計では苦しいような気もします。

以前、ここに私がした投稿を読んでみてください。
悩みが解決すると思います

[追記]
投票は1にしましたが、正確には「出来るだけクラス化」です。
労力に見合った成果が得られない時もありますので。

[ メッセージ編集済み編集者: ぽん編集日時 2004-07-10 19:57 ]

meltingpot: 常連さん; 会議室デビュー日: 2004/06/15; 投稿数: 24

投稿日時: 2004-07-12 10:50

DBアクセスのコンポーネントに限って言うと、うまくオブジェクト指向的なアプローチが適用できる場面が少ない気がしますが、経験上テーブルのキーになるデータだけはとにかくクラスによって抽象化しておくといいと思います。数値であろうが、コード化された文字列であろうが中身を気にしなく良くなるのですっきりします。

maru: ぬし; 会議室デビュー日: 2003/01/27; 投稿数: 412

投稿日時: 2004-07-12 14:18

こんにちは。
ぽんさんの教えてくださった記事を読んだのですが、はずかしながらいまだ漠然としていて
しっくりきていないのが現状です。勉強が足りないのか・・・。
私もmeltingpotさんの言われるのがよいのかなあという気が以前からしていました。

unibon: ぬし; 会議室デビュー日: 2002/08/22; 投稿数: 1532; お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)

投稿日時: 2004-07-12 15:26

unibon です。こんにちわ。

引用:

maruさんの書き込み (2004-07-10 17:08) より:
しかし実際には、顧客テーブルでも画面によっては一部の列しか呼び出す必要もなかったり、
1回のSQLの呼び出しで複数テーブルやマスタを結合して読み込んだり、複数テーブルで１トラン
ザクションだったり、１クラス＝１テーブルの設計では苦しいような気もします。

結局は OR マッピング(Object Relatiolal Mapping)の問題に行きつくと思います。しかし、OR マッピングをうまく実装するためには、なんらかのフレームワークの使用が不可欠だと感じます。フレームワークを使わずに自前で同等のことをやろうとすると、複雑すぎて破綻しやすいとも感じます。

丘波乗: 会議室デビュー日: 2004/04/13; 投稿数: 6

投稿日時: 2004-07-12 16:10

私もunibonさん同様の意見ですが、DAO(Data Access Object)パターンを導入すると比較的きれいに実装できると思います。(テーブル相当のクラスと、レコード相当のクラスに分離する)

maruさんの話を聞いていて思ったのですが、RDB系アプリから入るより、maruさんのように
非RDBアプリから入るほうがオブジェクト指向のメリットが実感できそうですね。
(RDB系はORMが面倒なため、安易にRDB中心のアーキテクチャを採りがちかなと思います)

meltingpot: 常連さん; 会議室デビュー日: 2004/06/15; 投稿数: 24

投稿日時: 2004-07-12 16:25

DAOパターンは私の関わったプロダクトでも大抵採用されてきました。
ただSQLをストアド中心で組んでいると、DBにDAOパターンで一皮被せることで煩雑さが増しているように感じられてあまりうれしくありません。

がるがる: ぬし; 会議室デビュー日: 2002/04/12; 投稿数: 873

投稿日時: 2004-07-12 17:03

ども。がるともうします。
んと、一つ提案を。
「とりあえず適当に作ってみる」というのはいかがでしょうか？
前に、こちらで講座を書かせていただいたときにもちょろっと
書いたのですが。
１テーブルは１クラスに。んで「確実にどのクラスに結びつくか
分かってる挙動」はそのクラスのメソッドに。
「これ、どこにいれよう？」って悩むものは、とりあえずそれら
全部を「ごみクラス」に:-P

とても個人的な見解ですが。
「がっつり完璧に」クラス設計をするよりも、「とりあえず」設計
して尻軽に「いつでも変更可能にするしっていうか変更してる」
ほうが、かえって後々のメンテに好影響を与えることが多いように
思います。
いやまぁ、時々インタフェースきり間違えて後で地獄を見たりも
するのですが。その辺はまぁ「火傷をして覚える」ものかなぁ、と :-P

なので、肩の力を抜いて「とりあえず」クラスを作ってみる、という
のもよいと思います ^^

1|2|3 次のページへ»

データベース系アプリケーションで、データや処理をどこまでクラス化する？

スキルアップ／キャリアアップ（JOB@IT）