ひがさんのBlogのまとめサイト(4)
画面遷移
画面のモックを使って早い段階から顧客に具体的なイメージを抱かせて、意識違いをできるだけ減らそうと。
画面モック→画面遷移図と落とし込んで、イメージしやすい画面遷移図を作るとともに、画面モック自体で実際の動作を見せようと。
Singleton
Singletonはテストと相性が悪い。なぜなら、テストメソッド間で状態を維持してしまうからだ。
2004-08-28 - ひがやすを blog
結構Singleton使ってました。
大体は設定ファイルの管理クラスで、読み込んだファイル内容をキャッシュしておくんでSingletonにしていただけだったんだけど、テストのときにモックに差し替えられないんで、ダミーの設定値を使いたいテストメソッドなんかで苦労した記憶が。
DTO
プレゼンテーション層と業務ロジック層のデータのやり取りは、EntityやDTOを使います。DTOを使うのは主に次のような場合です。
- 検索条件の入力データなど、永続化されないデータ。
- 関連のない複数のエンティティのやり取り。
御意。
プレゼンテーション層のフレームワークは、EntityやDTOと直接バインディングできることが望ましいのですが、Strutsなどを使っているとそうはいきません。そのような場合は、ViewHelperパターンを使います。ActionFormにEntityやDTOをセットして、相互変換するロジックをActionFormに組み込むのです。
2004-08-30 - ひがやすを blog(同)
JSFの場合、POJOに直接バインディングできるけどどうやるのがいいんでしょ。
プレゼンテーション層→業務ロジック層:
- A) JSFタグで直接POJOなDTOに値をバインディングする。(バウンダリ専用backing-beanと、フォーム情報DTOに特化したbacking-beanを用意しておくイメージ)
- B) JSFタグで(バウンダリ専用)backing-beanのフィールドに値をバインディングしておいて、actionに対応するメソッドでbacking-beanのフィールドの値をDTOに設定しなおす。
- C) JSFタグでbacking-beanのフィールドのDTOに値をバインディングする。
素直さからいって(A)なのかな?
まだJSFをいじった経験がほとんどないんで、まだあまりイメージわかないんですが。
S2JSFのサンプルをいじればわかるのかな?
業務ロジック層とデータアクセス層とのやり取りも同様です。
2004-08-30 - ひがやすを blog(同)
この下位の層間もモデル変換が必要ってことですか?
プレゼンテーション層とはきっちり切り離したいけど、データアクセス層は直接エンティティを知っててもいいような気がしますね。
業務ロジック層って場合によってはかなり薄くなるというか、DAOに委譲してあとちょこちょこっと簡単なことするかもしれない、くらいの実装になることが結構ありそうで。
そんなときに全体として、2回も層間をまたぐためだけの型変換をするのは冗長な感じが強いです。
- プレゼンテーション層/UIは変更が入ることが容易に予想されるので、影響範囲を狭くするためにプレゼンテーションモデル/DTOを使う。
- 業務ロジック層が扱うエンティティは仕様変更の可能性が小さいので、データアクセス層は直接エンティティを初期化する。
っていうイメージで今のところ理解します。
データアクセス層からエンティティへの依存が発生しますが、くーすだとエンティティ自体はどの層に所属しない無所属扱いでしたよね。
#関係ないけど、いつの間にかUI層じゃなくてプレゼンテーション層という呼称に統一されてますね。
業務ロジック
これまで、業務ロジッククラスは、バウンダリ(画面)ごとに作成することになっていましたが、業務フローごとに作成する方が良いかなと思っています。業務フローとは、関連する幾つかのバウンダリで構成されるものです。
2004-09-02 - ひがやすを blog
ある目的(ユーザ機能)のための処理を一箇所にまとめる、という観点から言えば、業務フローごとにまとめた方がわかりやすいと感じます。
バウンダリごとだと、あるフローを実現するためのメソッドが複数のクラスに分散することになりません?
パッケージ構成
くーすアプリケーションのパッケージは、ベースとなるパッケージの下に以下のパッケージで構成されます。
- form:フォームクラスを格納。
- action:アクションクラスを格納
- logic:業務ロジックのインターフェースを格納。
- impl:業務ロジックの実装クラスを格納。
- support:補助ロジックのインターフェースを格納。
- impl:補助ロジックの実装クラスを格納。
- dao:Daoのインターフェースを格納
- impl:あれば、Daoの実装クラスを格納。
- entity:エンティティクラスを格納。
- dto:DTOクラスを格納。
- util:ユーティリティクラスを格納。
- interceptor:あれば、インターセプタを格納。
- dicon:diconファイルを格納。
diconファイルは、以下のように管理します。
- フォーム、アクション、業務ロジックを業務機能ごとに集めたもの
- 名前は業務機能名.dicon
- alldao.dicon、allsupport.diconをinclude
- Strutsの場合、フォームは対象外
- Daoをすべて集めたもの
- 名前はalldao.dicon
- dao.diconをinclude
- 補助ロジックをすべて集めたもの
- 名前はallsupport.dicon
- dao.diconをinclude
ルートにあるapp.diconで、すべての業務機能名.diconをincludeします。
2004-09-20 - ひがやすを blog
これこれ。こういう情報がほしかった!
実装に対するマッピングがわからないとイメージしづらい人間なんで。
すっきりしてシンプルなパッケージ構成でいいですね。
コンポーネント設計書
実装上は、バウンダリから呼び出されるメソッドは、インターフェースになり、コンポーネント内からしか呼び出されないメソッドは、実装クラスのpublicメソッドになります。
内部からしか呼び出されないのに、実装クラスのpublicメソッドにするのは、テストをしやすくするためです。別にprivateメソッドでもリフレクションを使って呼び出せますが、コンポーネントを使う方は、インターフェースしか見ないので、特にpublicでも問題ないと思います。
2004-09-26 - ひがやすを blog
利用者は必ずインタフェースを通して利用すること。この制約を利用者に課しておけば、実装クラスで本来privateにするべきメソッドをpublicにしても問題ない。
この視点は自分には新しいです。かなり衝撃的。
確かにそうかもしれません。
テストもやりやすいですね。
でも、テストのためだけであれば、せめてpackage-privateかprotectedぐらいにしときたいですね。自分なら。
くーすの場合、コンポーネントはステートレスなので、事後条件は、
- こんな引数なら戻り値はこうなる。
- こんな引数なら引数はこう更新される。
- こんな引数ならこのメソッドが呼びだされる。
- こんな引数ならこの例外が発生する。
のように記述します。また、テストケースを洗い出すのに、
- 本来しなければならないこと。
- 〜ならば〜すること。
- 例外
を念頭におくと良いでしょう。
「〜ならば〜すること」は、注意が必要です。「〜すること」を別のメソッドに切り出して、「〜ならばこのメソッドが呼び出されること」という事後条件にしましょう。
「本来しなければならないこと」が複数ある場合も、「本来しなければならないこと」を別メソッドに切り出します。
2004-09-26 - ひがやすを blog(同)
なるほどー。
DTO再び
Entityを使う場合は、Entityの構造とプレゼンテーション層で必要とする構造が異なるため、ViewHelperをかませるというのが、ポピュラーな方法ですが、これが結構手間です。Entityとプレゼンテーション層のデータ構造の変換を入力と出力の両方でやる必要があります。
それだったら、最初からプレゼンテーション層で扱いやすい構造のDTOを定義して、やり取りした方がいいジャンという考えです。
2004-10-10 - ひがやすを blog
こう考えるとエンティティって結局何をするために存在するんでしょ?
前の記事で「振る舞いを持たない」ってあったし。
今回の記事によるとDTOの項目も永続化されうるようだし。
この記事の後半で
今お勧めのやり方は、Entityはテーブルと同じ構造にして、N:1などのリレーションは定義しない。永続化されるデータを持つDTOは、Entityを継承して、プレゼンテーション層に都合のいい項目を追加するというものです。
ってあるけど、DTOの方が余分にフィールドを持つんだとしたら、エンティティの方がDTOのサブセットみたいになる?
なんだかよくわかんなくなってきたけど、DTOマンセーってことでFA?
あ、もうちょっと先で「ローカルDTO」とか「DTOと振る舞い」って記事があるようだ。明日にはたどり着けるかな。
というわけで今日は「DTO」まで。以上。