ひがやすを技術ブログ

電通国際情報サービスのプログラマ

ダイコン時代の設計手法 - モデリング

ダイコン

モデリングは、

に分けられると思ってます。
振る舞いのモデリングは、ユースケースを

  • ユースケース固有のロジック
  • 共通のロジック
  • データアクセスのロジック

にブレークダウンしていくものです。
今回のテーマはデータモデリング。


データモデリングは、

の2つのアプローチが考えられます。
どちらを選択するのかは好みの問題なのですが、
DOAの方をお勧めします。
DOAはER分析という確立した方法があるのに対し、
OOAによるモデリングは、いまだ確立したものがなく、
試行錯誤しなければならないためです。



OO原理主義に陥ることなく、常に現実的であれ
ER分析した結果は、テーブルとテーブル間のリレーションで
表現されます。
最初は、テーブルのレイアウトをほぼ一対一にPOJO(JavaBeans)に
マッピングします。
次にリレーションを追加していきます。


リレーションは大きく分けて

  • N:1(自分から見て相手が一意に決まる)
  • 1:N(自分から見て相手が複数存在する)

になると思ってます。
リレーションを追加するのは、N:1のほうです。
1:Nは

  • リレーションが連鎖している場合、どこまでリレーションを自動で解決するかの制御が難しい(状況によって変わる可能性がある)。(リレーションを最初に解決する場合)
  • getterメソッドでリレーションを解決する場合、永続化層以外でSQL文が発行される可能性がある。
  • ソート順が状況によって変わる場合がある。

など、難しい問題があるので、魅力的に見えるかもしれませんが、
使わないことをお勧めします。
1:Nをコーディングしてもたいした手間ではありません。



List employees = dao_.getEmployees(dept.getDeptno());
JavaBeansではなく、Mapを使いたいという誘惑にかられるかもしれません。
型を失うペナルティは予想以上に大きいものです。
＃コンパイラは怒らないし、コードアシストも効かなくなる。


でも、O/Rマッピングのフレームワークって状況によっては必要のないデータも

全部とってくるジャン。効率悪いんだよね。

状況に応じて、JavaBeans作るのも保守が大変だし。

だったらMapが楽でいいジャン。
そんな声が聞こえてきそうです。
ダイコン時代のO/Rマッピングのフレームワークは、1つのJavaBeansに
必要なカラムだけをマッピングする機能も必要なのです。


後は、設計が進むに連れて見つかってくる導出属性を追加していくと良いでしょう。


追記:ダイコン時代の設計手法について、気になるテーマがあれば
コメントください。いっしょに考えましょう。