マジックビーンズ

引き続き『SQL アンチパターン』の話です。
24 章の内容は、仕事でプログラムを書いているときに、私もよく悩みました。

この章については、解決策に書かれているような簡単な話ではないと思っています。図 24-2 と図 24-3 を見比べると、コントローラとアクティブレコードの間にドメインモデルを挟むことで綺麗に解決したように見えてしまいます。ですが、現実的には、ここに出てくるドメインモデルを綺麗に設計することが、なかなか難しいのですよね。いきあたりばったりで実装していくと、コントローラが必要とする操作をすべて提供する巨大なユーティリティクラスのようになってしまったり、逆にコントローラと一対一対応に近いような細かなクラスを大量に作ることになってしまったり。

以前、『アジャイルソフトウェア開発の奥義』という本で、依存関係逆転の原則という内容を読んだときにも、同じことを思いました。つまり、隣接する二層間が多対多の依存でぐちゃぐちゃしているとき、中間層を作れば、理屈ではもちろん依存関係を整理できるわけです。実際には、その中間層のインタフェースを綺麗に設計することが難しくて、ああでもない、こうでもないと、考え込んでしまいます。

ところで、この章の 24.5.2 に掲載されているプログラムですが、これはどうもイマイチな感があります。一つは get 関数です。find した結果をそのまま返していますが、これではアクティブレコードがコントローラに見えてしまいます。つまり、コントローラは get 関数から戻されたアクティブレコードに対して、更新をかけたりレコードを削除したりできてしまいます。24.2.2 で述べられている問題を解決できていません。もう一つは search 関数です (get 関数も同じですが)。このコードでは、関数から戻されるオブジェクトのフィールド名は、データベースのカラム名によって決まりますので、24.2.1 で述べられているデータベーススキーマへの依存という問題が依然として残っています。

また、コード中の create 関数は 3 引数を取りますが、現実のシステムでは、もっと多くの引数を取る場合もあるでしょう。そうなると引数を構造体にまとめたくなります。上位層であるコントローラからアクティブレコードを隠蔽し、データベーススキーマへの依存を断ち切ろうとすれば、戻り値も同様に、構造体を作ってアクティブレコードの内容を詰め替えて戻すのでしょうか。これは結局 DAO, DTO といった話になるような気がします。悩ましいですね。