ORマッピング
まさか使うことになるとはねぇ～。ってまだ確定じゃないけど。ドメインを定義するとそれをベースにテーブルが生成されて、対応するCRUD画面も作ってくれる便利さは認める。素直に認める。ただその画面は客に見せられるシロモノではない。ヘッダーとフッターは変更必須。そしてドメインの列名をi18nで定義してやると...。もしかするとOKしてくれる客がいるかも知れない。
ORマッピングで設計するだろうか？
実世界はチュートリアルやマニュアルのサンプルみたいに綺麗じゃない。そもそもドメインを1:1, 1:n, n:nと洗い出せるか？「あとからドメインを追加・変更してもコードへ自動的に反映される」という声も聞こえてきそうだけど、それは自動生成されるCRUD画面の場合ね。だからあれはマスター登録用には使えるかもしれないけど、メインの業務用には無理だって。海の向こうの国ではああいった伝票ベースの画面でもOKらしいけど、日本はできるだけ少ない画面で業務をこなそうとするから、どうしても複雑になる。設計段階でボツになるのは確実。だからあまり旨味を感じられない。
パフォーマンスは？
下手に関連付けるとSELECT文が(N+1)問題*1を起こしかねない。UPDATEでも起こりえる。最近のDBサーバーなら数万件オーダーのテーブル同士なら、完全外部結合(full outer join)しようが何しようが大丈夫でしょう。それにORマッパーも「遅延hogehoge」といった手段を提供しているし。でも相手が数千万件オーダーのテーブル群だとしたら？大丈夫なんだろうか？
じゃぁ関連付けやめたら？
そうね。あの擬似SQLでコーディングしろ、っことよね。それを開発者全員に強いるのか。うーん、使いこなせるようになるまでどのくらい時間がかかるんだ？サーバ側にViewを定義して、それをドメインへマップすることも考えられるけど、やっぱりパフォーマンスが心配だ。それに更新は事実上できない*2。なおさら使う意味が無い。
どうするの？
はぁ。いやフレームワーク採用の可否を決めるのはドナドナ先だから。私はそれに従うまで。ただ、もし自分が責任者だったら...。あれ、また今夜も来客か...。
