Action-Service-Logic の3階層は冗長か？ - 出羽ブログ
エンティティ固有のドメインロジックは別出しにします。 ひがさんが最近呼んでる「Service」に近いです。 でも、みなさん Action-Service-Logic の3階層は冗長ってお考えなんですね。 そうでもないですよ。今、私が携わらせて頂いている案件では、 Action ： コントローラ Service： ユースケース単位のロジック + データアクセス Logic ： エンティティ単位のロジック + データアクセス ※ LogicはActionとServiceの両方から呼び出し可能とする。の方式に数人の中核のメンバーから納得感を得ています。 無難な選択肢だと思います。 一見冗長に思えますが、「ユースケース単位のロジック」と「エンティティ単位のロジック」を１種類のクラスに寄せる方式はどこかで無理が生じてしまいます。そう考えると、この方式は自然な発想ではないでしょうか。 この方式のポイン
2008-05-08 - 出羽ブログ ～ はてな版 ～ スケールするアクション
特定のユースケースへの要件が少ない場合は、 ユースケースに対応した１つのActionクラスで基本的な処理は実装できます。 しかし、ユースケースへの要件が多い場合は、扱うクラスが増えてしまいます。 例えば、ユースケース専用のDto(ActionForm)やユースケース専用のLogic、セッション格納用Dtoなどです。 特定のユースケースに関するクラスが複数存在する場合は、 パッケージが分散しているよりも、１つのパッケージに集めた方が開発しやすいと思います。 (Teedaはこのような構成でした。) そこで、ユースケース名が "hoge" の場合、以下のような構成が可能なように SAStrutsを拡張してみました。 Java側： ＜ルートパッケージ＞.web.hoge.HogeAction.java ＜ルートパッケージ＞.web.hoge.HogeDto.java (ActionForm) ＜ル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
