ひがさんのBlogのまとめサイト (5)
wikiroom.com 閉鎖
を読んで勉強するシリーズ第5弾
今日は短めに。
TransactionScript (by Fowler)
くーすでは、業務ごとにニーズなんか違うんだから、それぞれの業務ごとに、SELECT文は、最適化したものを使います。ある意味、SQLにロジックが埋め込まれているわけですが、RDBMSを使ってパフォーマンスを稼ぐには、それが一番だと思っているわけです。
これが、ドメインオブジェクトではなく、DTOを使うということにもつながってきます。
2004-10-21 - ひがやすを blogTransactionScriptが、扱うデータを一度に読み込み、ループでまわして、必要なものをセレクト、ということなら、くーすは違います。
最初から、SQLで必要なデータの必要な項目に絞って取得するからです。
Fowlerの言っているリッチなSQLですね。
SQLにロジックを埋め込むのと引き換えに、パフォーマンスを得ているわけです。
2004-10-21 - ひがやすを blog
TransactionScriptとの比較によって、くーすの位置づけがだいぶ具体的に見えてきました。
ホントに薄い業務ロジック層を目指しているわけですね。
ドメインモデル
ドメインモデルは、オブジェクト指向設計のキーとなる考え方で、次のような長所があると私は考えています。
- ロジックは、SQLではなく、ドメインオブジェクトにおかれるので、修正するときに、修正かしょを探しやすい。
- ロジックが重複することが比較的少ない。
短所としては、
- 設計が難しい。
〜(省略)〜
- プレゼンテーション層で扱うのが難しい。
〜(省略)〜
OpenSessionInViewを使うことも望ましくありません。層で役割を分けるという考えと矛盾しています。プレゼンテーション層では、少しでも例外が起きそうなことは避けるべきです。プレゼンテーション層に渡すデータは、完全にコネクションからは、切り離されている必要があります。
2004-10-22 - ひがやすを blog
なるほど、OpenSessionInViewにはそういうリスクがあるわけか。
こう考えていくと、プレゼンテーション層に渡すデータは、プレゼンテーション層で扱いやすい形式のDTOにする。DTOとドメインオブジェクトの相互変換をするのもコストがかかるので、データアクセス層で、最適化されたSQLを発行して直接DTOにマッピングする方が、パフォーマンスも良く、コストもかからないと思うわけです。
2004-10-22 - ひがやすを blog(同)
All-DTOというか、ユビキタスDTOというか。そういう感じ、シンプルで結構好きかも。
でも、最近のblogだと、プレゼンテーションモデルとドメインモデルの変換とかいうネタがあった気がする。ドメインモデル復権ですか？
もちろん、この方法も最適解ではなく、SQLにロジックが入り込むというリスクを犯しています。
2004-10-22 - ひがやすを blog(同)
それも1つのリスクなんですね。φ(。_。)メモメモ
面倒なので大雑把にまとめてしまうと．．．
- Transaction Script
- Domain Logic を「手続き」に配置する．
- Domain Model
- Domain Logic を「データ」と一緒に配置する．
ちなみに SQL の複雑さとかは関係ないみたい．何も書いてない気がします．
2004-10-22 - 日記
あ、そうなんですか。結構シンプルですね。
それにさりげなくTable Moduleもよさげですか。
紹介されてる↓の本もチェックしておこうっと。
- PofEAA (PofEAA's Wiki - FrontPage]
- UML によるビジネスモデリング (isbn:479731382x)
これをうけてひがさん↓。
FowlerのいっているTransactionScriptは、(たぶん)従来の手続き型ですね。こういちさんのいっている通り、monolithicなイメージなんじゃないかと思います。
くーすでは、役割に応じて、クラスは分かれます。
- 業務固有のクラス
- データアクセス用のクラス
- 複数の業務から共通に使われるクラス
リッチなSQLの話を除けば、どのロジックがどこにあるのかが明確で、ロジックが重複することはありません。
また、Statelessであるということも重要です。
2004-10-23 - ひがやすを blog
分割して統治せよ、でしたっけ。
-
-
- -
-
短いけどねむいのでここまで。
以上、「TransactionScriptとStateless BusinessLogic」まで。
