ダイコン時代の設計手法 - モデリング
モデリングは、
に分けられると思ってます。
振る舞いのモデリングは、ユースケースを
- ユースケース固有のロジック
- 共通のロジック
- データアクセスのロジック
にブレークダウンしていくものです。
今回のテーマはデータモデリング。
データモデリングは、
の2つのアプローチが考えられます。
どちらを選択するのかは好みの問題なのですが、
DOAの方をお勧めします。
DOAはER分析という確立した方法があるのに対し、
OOAによるモデリングは、いまだ確立したものがなく、
試行錯誤しなければならないためです。
ER分析した結果は、テーブルとテーブル間のリレーションで
OO原理主義に陥ることなく、常に現実的であれ
表現されます。
最初は、テーブルのレイアウトをほぼ一対一にPOJO(JavaBeans)に
マッピングします。
次にリレーションを追加していきます。
リレーションは大きく分けて
- N:1(自分から見て相手が一意に決まる)
- 1:N(自分から見て相手が複数存在する)
になると思ってます。
リレーションを追加するのは、N:1のほうです。
1:Nは
- リレーションが連鎖している場合、どこまでリレーションを自動で解決するかの制御が難しい(状況によって変わる可能性がある)。(リレーションを最初に解決する場合)
- getterメソッドでリレーションを解決する場合、永続化層以外でSQL文が発行される可能性がある。
- ソート順が状況によって変わる場合がある。
など、難しい問題があるので、魅力的に見えるかもしれませんが、
使わないことをお勧めします。
1:Nをコーディングしてもたいした手間ではありません。
JavaBeansではなく、Mapを使いたいという誘惑にかられるかもしれません。
List employees = dao_.getEmployees(dept.getDeptno());
型を失うペナルティは予想以上に大きいものです。
#コンパイラは怒らないし、コードアシストも効かなくなる。
そんな声が聞こえてきそうです。
でも、O/Rマッピングのフレームワークって状況によっては必要のないデータも
全部とってくるジャン。効率悪いんだよね。
状況に応じて、JavaBeans作るのも保守が大変だし。
だったらMapが楽でいいジャン。
ダイコン時代のO/Rマッピングのフレームワークは、1つのJavaBeansに
必要なカラムだけをマッピングする機能も必要なのです。
後は、設計が進むに連れて見つかってくる導出属性を追加していくと良いでしょう。
追記:ダイコン時代の設計手法について、気になるテーマがあれば
コメントください。いっしょに考えましょう。
仮面をかぶる
潜在意識は無意識に行動を規制する。逆に言えば、こいつによいイメージをたたき込んでおくとそのイメージのままオートパイロットのように行動できる。これがスポーツ選手のやるイメージトレーニングってやつだ。
私はこれを高2の時からやっている。
イメトレのつもりでも成功哲学の影響でもない。
そう、ガラスの仮面の影響だ。(笑)
1000の仮面を持つ少女、北島まやは時々こうつぶやく
そうして、仮面をかぶり役になりきるわけだ。
私は仮面をかぶる
高2のころの単純な私は、直ぐに影響された。
かぶった仮面は速水真澄(紫のバラの人)のものだ。
俺も仮面をかぶろう
それからいろんな仮面をかぶってきたけど、速水真澄の仮面は
はずしたことがない。
私がもしクールに見えることがあるなら、それは私自身のものではない。
きっと、私から見た速水真澄のイメージだろう。