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

[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って必要ないんじゃないの？とも思
> います。

必要かどうかは作成するアプリケーションの複雑さに
依存しますが，必要性を感じないのならシンプルに
始めるのがいいのではないでしょうか．


-- 
<component name="koichik">
    <property name="fullName">"Koichi Kobayashi"</property>
    <property name="email">"[E-MAIL ADDRESS DELETED]"</property>
    <property name="blog">"http://d.hatena.ne.jp/koichik"</property>
</component>