アクションは、複数の実行メソッド を持つことができ、
通常は、1ユースケースを1アクションにマッピングします。
複数の画面で構成される意味のある単位をユースケースだと、
とらえればよいでしょう。
http://sastruts.seasar.org/featureReference.html#Architecture
1画面1Actionではなく、1ユースケース1Actionということになると、
ユースケースの粒度をどう見るかが重要になってきます。
例えば、商品マスタメンテナンス機能の場合
画面１：検索条件の入力と検索結果の一覧を表示する
画面２；商品情報の新規登録または画面１で選択した商品の修正・削除を行う
画面３：店舗別の商品情報の修正を行う。
※画面２、画面３それぞれでDB更新を行う。
今回、私が考えているユースケースの粒度は
・商品情報を検索する
・商品情報と登録・修正・削除する
・店舗別の商品情報を修正する
の３つになります。
今回の場合は、結果的に1画面1Actionになってしまいますが
例えば商品情報が、画面に項目が入りきらないなどの理由で
２つの画面に分けて表示する場合は、
その２つ画面で１つのActionになるべきだと考えています。
理由は、
１．入力チェックが画面１、画面２、画面３で独立している点
２．画面２、画面３でそれぞれDB更新する点
※ウィザードのような入力画面であれば1Actionの方がいいと思いますが・・・
です。
いかがでしょうか？
4 件のコメント:
なぜウィザードのような入力画面であれば1Actionの方がいいんですか？
こんばんわ、ZIGENです。
６年ぐらい前の記事にコメントがきたので
びっくりしました。
質問の回答ですが、
例えば、Eclipseの新規クラス作成やソフトウェアをインストールするウィザード画面を考えた時、
「新規にクラスを作成する」
「ソフトウェアを追加する」
といったユースケースに分割できるため、
それぞれ１Actionが良いと思いました。
また、ウィザードは複数の画面に分割されることが
ほとんどですが、途中のページの情報はデータベース
永続化せず、セッション情報として一時的に保持する
ことが多いと思っているからです。
各ページでは、１つのActionFormを持ちまわり、最後のページのボタンを使って、データベースを更新するほうが、いいのでは？と思ったのだと思います。
６年も月日がたつと、、もっといいやり方が
あるのかもしれませんね・・・
回答ありがとうございます。今後の参考にします。
今SAStrutsを使って開発をしているのですが、
アクションクラスの単位についてとても困っています。
２画面構成で１画面目は情報一覧リスト・追加・更新・削除ボタンがあります。
追加・更新ボタンを押下した際は２画面目の登録画面へ遷移し、登録画面にある
登録ボタンを押下することでそれぞれ処理が実行されるというものです。
ZIGENさんならどのようにアクションの単位を決めますか？
重宝にさせていただいています。
目に優しくと思い、ダーク系でEclipseを使うようになりました。
そのためにテーブル編集エディターの奇数行（偶数行は背景色が設定可）が見えなくなり、不便な状況になっています。
いろいろ設定を試行しましたが叶わず、なにか方法があればお教え願えれば幸いです。
コメントを投稿