SourceForgeのダウンロード総計
が3万件を突破しました。
みなさん、これからもよろしくお願いします。m(_ _)m
ドメインモデルの長所と短所
ドメインモデルをここでは
業務固有の重要なオブジェクトとそのオブジェクト間の関係をモデル化したもの。
と定義して話を進めます。ドメインオブジェクトは、POJOとして、データアクセスロジックからは切り離されているという前提です。
ドメインモデルは、オブジェクト指向設計のキーとなる考え方で、次のような長所があると私は考えています。
短所としては、
- 設計が難しい。
これは、ドメインにおけるパターンが、普及しない限り難しいと思います。かといって、アナリシスパターンみたいなものも、また違う気がします。
- プレゼンテーション層で扱うのが難しい。
プレゼンテーション層で扱う(欲しい)データの形式は、フラットな構造か、フラットな構造の配列であることがほとんどです。また、もともとのデータをいろいろ加工して表示することもあります。それに対し、ドメインオブジェクトの構造は複雑です。この両者のギャップを埋めるのが、ViewHelperですが、このViewHelper結構作るのにコストがかかります。
後、あまり触れられていない問題ですが、ViewHelperを誰が作るのかです。もちろん、プレゼンテーション層でしょって思われるかもしれません。
しかし、Hibernateを使って、ドメインモデルを構築したとしましょう。lazy-loadingを使っていた場合、ViewHelperがドメインオブジェクトのメソッドを呼び出したときに、SQL文が発行される可能性があります。
これは、もちろん望ましくありません。OpenSessionInViewを使うことも望ましくありません。層で役割を分けるという考えと矛盾しています。プレゼンテーション層では、少しでも例外が起きそうなことは避けるべきです。プレゼンテーション層に渡すデータは、完全にコネクションからは、切り離されている必要があります。
こう考えていくと、プレゼンテーション層に渡すデータは、プレゼンテーション層で扱いやすい形式のDTOにする。DTOとドメインオブジェクトの相互変換をするのもコストがかかるので、データアクセス層で、最適化されたSQLを発行して直接DTOにマッピングする方が、パフォーマンスも良く、コストもかからないと思うわけです。
もちろん、この方法も最適解ではなく、SQLにロジックが入り込むというリスクを犯しています。
