http://d.hatena.ne.jp/dewa/20080320#1205988539 [欲しいものは明示的に] DBFluteは、自動LazyLoad機能(Getしたときに検索)は存在しません。 なので、明示的にSetupSelectもしくはLoadReferrerしていない関連テーブルは、 getしてもnullとか空リストとかが戻ります。 DBFluteは、利用する処理(画面やバッチ)側が「何が欲しいのか」を意識します。 これは今の時代のDBアプリのインフラ状況から、それが一番安全だと判断したからです。 パフォーマンス問題の原因で「無駄なSQLの発行しすぎ」がかなり多く、 プログラマは「まだ今の時代は」RDBを意識して効率の良いDBアクセスをすべきだと。 無論、オンメモリデータベースもしくはオブジェクトデータベースが主流になってきたら、 その辺のポリシーは変わるでしょう。ただ、それはまだまだ先の話ではないかなと。 [ドメインロジック] Entityのロジックに関しては、あえて実装するなら導出列程度のロジックが 個人的にはいいかなと思います。リッチドメインだとかどうのこうの以前に、 EntityはDI管理じゃないので、普通にロジックが書きづらい領域だと考えます。 (これ実際自分がやろうとして思ったことです) なので、ドメイン領域(テーブル単位のクラス)のロジックを扱いたい場合は、 DBFluteならBehaviorに実装するのが良いかと思います。 (Behaviorという名前はもともと「データの振る舞い(Behavior)」なので) しかし、そもそも実際の開発で、ドメインロジックというものを意識するのは 難しいことかと思います。なぜなら、仕様書自体がが画面基点で設計されている ことが多いからです。やるなら設計自体もリッチドメインでやるべきかなと思います。 設計は画面ドリブンで、実装はリッチドメインと食い違っているのは良くないかなと。 そういう観点から言うと、ビジネスロジックの再利用設計は、実装視点だけでどうにか するものではなく、仕様書を作成する設計時点でしっかり固めておくべきかと 個人的には思います。(リッチドメインとかそうじゃないとか関係なく) それをやるには画面設計者とDB設計者をもっともっと近い関係で作業させるってのは もちろんのこと、ドメイン設計者って明確な役割を置くようなマネジメントをするかな。 (見積もりの時点でその分の工数調整もしないといけませんね...) この辺は実際にそうやったことないのでちょっと思いつきですw # # ２年ほど前のDBFlute(まだその名前がなかったとき)は、実は自動LazyLoadを # サポートしてましたが(Torqueを引き継いで)、すぐにやめました。 #
