[Seasar-user:15087] Re: [teeda]クラス・パッケージ構成について

["元場 羊二郎(Youjiro Motoba]

小林様

早速のご回答ありがとうございます。
頂いた情報とても分かりやすく助かりました。

個人的にはMiddle Patternが一番しっくりきますね。

> 画面の項目数が非常に多い場合，Page と Action を分離すると
> ソースの見通しがよくなりますが，最近はあまり好まれて
> いないかも．

ん〜、そうですか。個人的には分けたい派です。
(こーだから絶対分けたい！って断固とした理由はないんですけど
ね。。)

> 依存しますが，必要性を感じないのならシンプルに
> 始めるのがいいのではないでしょうか．

そうですね。S2JSFでしか開発したことがなく、teedaってすごそう
だけどどんな感じなんだろう？って段階なので、シンプルな構成で
試してみていきます。

それにしてもDoltengってすごいですねぇ〜。もっと早く勉強しと
けばよかったです。
さくさくきれいに作っていけるように頂いた情報を元に勉強しま
す！ありがとうございます！

以上、宜しくお願い致します。

Koichi Kobayashi さんは書きました:
> 小林 (koichik) です．
> 
> Date:    Thu, 17 Jul 2008 23:19:02 +0900
> From:    "元場 羊二郎(Youjiro Motoba)" <[E-MAIL ADDRESS DELETED]>
> To:      [E-MAIL ADDRESS DELETED]
> Subject: [Seasar-user:15084] [teeda]クラス・パッケージ構成について
> 
>> teedaを使った場合の推奨するクラス・パッケージ構成はどのよう
>> にすれば宜しいでしょうか？
>> Page、Service、Logicをどのような構成にすべきか悩んでます。
> 
> 以下の記事が参考になると思います．
> 
> http://d.hatena.ne.jp/szk-takanori/20070304/1173022251
> 
> パッケージ構成についてはこちらも参照してください．
> 
> http://s2container.seasar.org/2.4/ja/DIContainer.html#SMARTdeployPackage
> 
>> 多分、各クラスが何を意味するか理解できてないことが原因だと思
>> うのですが・・・
>>
>> ◆Page
>> ⇒htmlのid属性をプロパティとするJavaBeans？
>> ⇒サブアプリ固有のロジック？
> 
> Teeda の Page クラスは画面単位なので，画面固有の
> ロジックになります．
> ロジックといってもプレゼンテーションに関するものに
> 限定する場合もあります．
> 
>> ◆Action
>> ⇒サブアプリ固有のロジック？
> 
> Page クラスにはプロパティだけを持たせて，画面固有の
> ロジック (initialize, prerender, do〜) を分離したものです．
> 画面の項目数が非常に多い場合，Page と Action を分離すると
> ソースの見通しがよくなりますが，最近はあまり好まれて
> いないかも．
> 
>> ◆Service
>> ⇒？？？
> 
> 元々は画面 (プレゼンテーション) から切り離された
> ビジネスロジックとかドメインロジックとか業務ロジックとか
> 呼ばれるものへのエントリポイント (ファサード)，あるいは
> プレゼンテーションレイヤとドメインレイヤの橋渡しを
> 担うクラス．
> 
> http://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?ServiceLayer
> 
> この場合の Service はサブアプリケーション単位に
> 作られることが多かったのではないかと思います．
> 
> 最近はエンティティと 1対1 で作成する，エンティティ固有の
> ロジックを持つクラスのことを Service と呼ぶようになって
> きましたが，これは上の説明とは別物です．
> 
>> ◆Logic
>> ⇒共通ロジック？	
> 
> 画面 (プレゼンテーション) から切り離された
> ビジネスロジックとかドメインロジックとか業務ロジックとか
> 呼ばれるようなロジック．
> 
>> また、PageとActionを分離とか出来たりもするのですが、どんな時
>> に分離するのでしょう？
>> もしかして、ActionとServiceって必要ないんじゃないの？とも思
>> います。
> 
> 必要かどうかは作成するアプリケーションの複雑さに
> 依存しますが，必要性を感じないのならシンプルに
> 始めるのがいいのではないでしょうか．
> 
> 
//
motoba