[Seasar-user:20453] Re: ソース階層分けについて

[Yuzuru Funakoshi]

吉田様

ご返信ありがとうございます。

> あくまで自分の場合ですが、1ユースケースで1Service作成を基本にしています。
>
> 例えば、ユーザマスタ保守といったユースケースがあった場合、Actionには
> action.User.IndexAction - 一覧とか
> action.User.EditAction - 編集画面とか
> を作成し、Serviceは1つのみで
> service.UserService
> を作成し、これに一覧表示用データを返すメソッドやformからDBを更新するメソッド 
> 
> を実装していきます。

> ユーザマスタ・組織マスタの更新処理をそれぞれ分けたいのであれば、別のServiceに
> 実装し、UserServiceのメソッドから各々の更新メソッドを分けるようにするかもしれません。
> #自分なら、分けないでしょうけど:-)

私もおっしゃれるようなイメージです。どのJavaプロジェクトもビジネスロジック層は複数のDAOを１ユースケースで使いこなしていますし。

なにぶん、趣味で興味がてらにSASｔruｔｓに触れ基礎も分かっていない状態です。これらの共通ビジネスロジック(色々なActionから呼ばれる)はActionのスーパークラスに入れてましたので。ものすごい違和感を感じていました。[１Serviceクラス=１テーブル]と言う訳ではないのですね。

@Generated(value = { "S2JDBC-Gen 2.4.41",
  "org.seasar.extension.jdbc.gen.internal.model.ServiceModelFactoryImpl" }, 
date = "2010/08/20 2:48:14")
public class AnounceTblService extends AbstractService<AnounceTbl> {

↑自動生成したServiceクラスはこのように生成され、[１Serviceクラス=１テーブル]と思い込んでいました。何もentity(AnounceTbl)を固定で使わずとも良いのですね。

ありがとうございました。


>> [１Serviceクラス=１テーブル]となるとどうしても、他テーブルのトランザクションを
>> 他のテーブルのServiceに含めたくないと思ってしまいます。
>
> Doltengで生成されたプロジェクトであれば、Actionの実行開始とともにトランザクションが開始
> されるので、Serviceでのトランザクションは特に意識しなくてもいいとおもうのですが・・・
> どういった部分で悩んでいるのが、もうちょっと具体的にわかるといいかも
> _______________________________________________
> Seasar-user mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-user