- PR -

strutsのアクションの分割

1
投稿者投稿内容
roushi
常連さん
会議室デビュー日: 2003/07/18
投稿数: 28
投稿日時: 2003-10-21 11:39
こんにちは。
strutsを勉強しているのですが
少し疑問がわきました。
strutsにはLookupDispatchActionという
ボタンの処理分けのためのクラスがありますが
基本的にはLookupDiipatchActionはボタンの処理を分けて
それぞれのボタンのアクションは別に作成する方が
よいと書籍に書いてありました。
たしかにActionに対して1つの機能に統一した方がよいとは
思いますが・・・。

例えば、仮にJSPには複数のボタンがあり
各ボタンはそれぞれのボタンに対応した画面への遷移のみを行うとした場合

●好ましくない？？------------------------------------------------------
hogeLookupDispachAction(LookupDispachActionを継承した)クラス内で

//ボタンとメソッドのマッピング
protected Map getKeyMethodMap() {
Map map = new HashMap();
map.put("button.hoge1","hoge1");
map.put("button.hoge2","hoge2");
return map;
}

public ActionForward hoge1(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
return mapping.findForward("gamen1niseni");
}

public ActionForward hoge2(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response){
throws Exception {
return mapping.findForward("gamen2niseni");
}


struts-config.xmlの内容

<action path="/hogeLookupDispachAction"
type="study.action.hogeLookupDispachAction"
name="hogeForm"
parameter="action">
<forward name="gamen1niseni" path="/gamen1.jsp"/>
<forward name="gamen2niseni" path="/gamen2.jsp"/>
</action>
と記述した方がわかりやすいと思うのですが・・・。

●終了-------------------------------------------------------------------


たかだがボタンによる処理分けのために
ボタンごとにActionを作成しなければならないのでしょうか?

●推奨？？------------------------------------------------------

hogeLookupDispachAction(LookupDispachActionを継承した)クラス内で

//ボタンとメソッドのマッピング
protected Map getKeyMethodMap() {
Map map = new HashMap();
map.put("button.hoge1","hoge1");
map.put("button.hoge2","hoge2");
return map;
}

public ActionForward hoge1(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
return mapping.findForward("gamen1niseni");
}

public ActionForward hoge2(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response){
throws Exception {
return mapping.findForward("gamen2niseni");
}


struts-config.xmlの内容

<action path="/hogeLookupDispachAction"
type="study.action.hogeLookupDispachAction"
scope="session"
name="hogeForm"
parameter="action">
<forward name="gamen1niseni" path="/hoge1.do"/>
<forward name="gamen2niseni" path="/hoge2.do"/>
</action>

<action path="/hoge1"
type="study.action.hoge1"
scope="session"
name="hogeForm">
<forward name="gamen1niseni" path="/gamen1.jsp"/>
</action>

<action path="/hoge2"
type="study.action.hoge2"
scope="session"
name="hogeForm">
<forward name="gamen1niseni" path="/gamen2.jsp"/>
</action>

何か逆にわかりにくくなっているような気がするのは私だけでしょうか・・・。
ボタンを押した場合に特に業務ロジックを呼び出したりしなくて
画面遷移のみしたい場合はLookupDispachAction内で
完結したほうがよいと思いますが・・・。
これは好みの問題になるのかな？

どなたか指針などあればお聞かせ下さい。
よろしくお願いします。
とまと
ベテラン
会議室デビュー日: 2003/10/18
投稿数: 51
投稿日時: 2003-10-21 14:14
こんにちは。

引用:

roushiさんの書き込み (2003-10-21 11:39) より:
strutsにはLookupDispatchActionという
ボタンの処理分けのためのクラスがありますが
基本的にはLookupDiipatchActionはボタンの処理を分けて
それぞれのボタンのアクションは別に作成する方が
よいと書籍に書いてありました。
たしかにActionに対して1つの機能に統一した方がよいとは
思いますが・・・。


なんという書籍でしょうか？
私の持っている書籍(Programming Jakarta Struts、オライリー)には、
「DispatchActionクラスの目的は、通常は複数のActionクラスに散在する、
複数のオペレーションを1つのクラスに置けるようにすることです。
1つのサービスに関連する操作があれば、複数のActionクラスに分散する
のではなく、同じクラスに保持すべきだという考えです。」
と記述されています。
私は次のように理解しています。
１．LookupDispatchActionを利用すれば、同じ名前の複数のサブミット
　ボタンがある場合（国際化を考慮する必要がある）ような場合、
　押したボタンの種類によってどの処理を呼び出すかといった制御が
　簡単に実現できる。
　そして、LookupDispatchActionを使用するのはこのケースだけである。
２．1つのサービスに関連する操作を処理するには以下の方法がある。
（１）それぞれの操作を別Actionとして実装する。
（２）DispatchActionに関連する操作をまとめる。
（２a）roushiさんの書籍で推奨しているような、DispatchActionで
　　　対応する操作Actionにフォワードする方法。
　　　これは（２）の１つの例である。
（３）自前のActionクラスでどの操作が選択されたか判断し、
　　　対応する処理を実行する。

・1つのサービスに関連する操作をまとめた方が
　わかりやすければ(2)を採用。
・小規模なシステムでは、単純で理解しやすいモデルである
　(1)を採用しても問題ないかもしれない。
　Actionクラスの数や設定ファイルの肥大化による
　保守コストなどをなんらかの方法で制御する必要があるかも。
・(2)と(2a)の使い分はよくわからない（笑）。
　操作ActionをDispatchAction経由以外に呼び出すケースが
　ある場合。押されたボタンの種類だけではなく、
　その他にも判断しなければならない要素がある場合、
　DispatchActionで判断し、さらに別のActionにフォワード
　するような場合。
・(3)はDispatchActionがよく理解できない頭の固いエンジニアあるいは
　コントロールは俺に任せろといった制御系エンジニア向け(kidding)。
　あるいは、複雑な判断をして実行する処理を決定する必要がある場合。

<最終的な結論>
どの方式を採用するかはケースバイケースであり、
開発コスト、品質の確保、保守性、メンバのスキルを考慮し、
アーキテクトが決定する（笑）。

引用:

例えば、仮にJSPには複数のボタンがあり
各ボタンはそれぞれのボタンに対応した画面への遷移のみを行うとした場合
<snip>


私の場合。
・たかがjspの呼び出しぐらいでActionクラスを作っていたら、
　管理・保守するのがたいへんだ。
---> 各操作に対するActionクラスは作らない。

・これらの操作をDispatchActionクラスにまとめるか？
---> そのボタン操作が1つのサービスに関連する処理ならば
　　　 DispatchActionにまとめることは十分考えられる。
　　　 サービスに関連しないボタン押下（例．トップページに戻るなど）
　　　　はそのDispatchActionにはまとめない。
　　　　お遊びプログラミングあるいは小規模システムならば、
　　　　DispatchActionにまとめずに、
設定ファイルにそのJSPに対するForwardActionを
　　　　定義し、ボタンが押されたら直接そのフォワードアクション
　　　　を起動するようにする。
　　　　大規模システムでもそうするかも（笑）。

という感じになるでしょうか。

こういった設計は絶対的な決まりなどなく、
様々な状況を考慮して最終的には一人の設計責任者が
決定することになると思います。
このようなことを複数の人が集まって
決めようとすると、
意見があわなくてなかなか決まらなかったり、
お互いにいやな気分になったりします（笑）。
ただ参考にいろいろな人の意見を聞くことは
良いことだとは思います。


[ メッセージ編集済み 編集者: とまと 編集日時 2003-10-21 14:49 ]
roushi
常連さん
会議室デビュー日: 2003/07/18
投稿数: 28
投稿日時: 2003-10-21 14:54
さっそくのお返事ありがとうございます。

私が参考にしている本は
カンタンStruts1.1 改訂版です。

そこには
設計のポイントとして
LookupDispatchActionの各メソッドに通常のActionクラスの
executeメソッドと同様の処理を記述することができる。
しかしそのように実装してしまうと本来は複数のActionクラスに
分割するべき処理を一つのActionクラスに実装することになり
メンテナンス性が低下してしまう。
LookupDispatchActionでは振り分け処理のみを行い、
実際の処理は別のActionを定義して実装する設計を推奨しています。

とありました。

引用:----------------------------------------------------------

私は次のように理解しています。
１．LookupDispatchActionを利用すれば、同じ名前の複数のサブミット
　ボタンがある場合（国際化を考慮する必要がある）ような場合、
　押したボタンの種類によってどの処理を呼び出すかといった制御が
　簡単に実現できる。
　そして、LookupDispatchActionを使用するのはこのケースだけである。

---------------------------------------------------------------
同じ名前の複数のサブミットボタンがある場合というのを
具体的に例を示してもらえないでしょうかm(__)m?
--------------------
botton.update = 追加
botton.update = 更新
--------------------
botton.add = 追加
botton.insert = 追加

こんなパターンでしょうか??


引用:----------------------------------------------------------
私の場合。
・たかがjspの呼び出しぐらいでActionクラスを作っていたら、
　管理・保守するのがたいへんだ。
---> 各操作に対するActionクラスは作らない。

---------------------------------------------------------------
私も同意見です
ごちゃごちゃしてわかりにくくなりますからね


引用:----------------------------------------------------------
・これらの操作をDispatchActionクラスにまとめるか？
---> そのボタン操作が1つのサービスに関連する処理ならば
　　　 DispatchActionにまとめることは十分考えられる。
　　　 サービスに関連しないボタン押下（例．トップページに戻るなど）
　　　　はそのDispatchActionにはまとめない。
　　　　お遊びプログラミングあるいは小規模システムならば、
　　　　DispatchActionにまとめずに、
設定ファイルにそのJSPに対するForwardActionを
　　　　定義し、ボタンが押されたら直接そのフォワードアクション
　　　　を起動するようにする。
　　　　大規模システムでもそうするかも（笑）。
---------------------------------------------------------------

戻るボタンなどの場合は,Validatorを使っている場合だと
戻るボタンを押下した時にも、入力チェックが走ってしまい
入力項目に正しい値を入力していないと
戻るボタンを実行することができないいう話を聞いたことがあります。
そこで戻るはJavaScriptで記述し
JSPのformタグ内にいれないようにすれば解決できるらしいですね。
そのときの戻ったときのJSPの値はどうなっているんだろうか・・・。


引用:----------------------------------------------------------

こういった設計は絶対的な決まりなどなく、
様々な状況を考慮して最終的には一人の設計責任者が
決定することになると思います。
このようなことを複数の人が集まって
決めようとすると、
意見があわなくてなかなか決まらなかったり、
お互いにいやな気分になったりします（笑）。

---------------------------------------------------------------

たしかに複数人で設計をする場合には
いくつかの持論を持ち合わせている人(頑固?)がいるので
収集がつかなくなることはありますね(笑)

とまと
ベテラン
会議室デビュー日: 2003/10/18
投稿数: 51
投稿日時: 2003-10-21 15:28
こんにちは。

引用:

roushiさんの書き込み (2003-10-21 14:54) より:
私が参考にしている本は
カンタンStruts1.1 改訂版です。

なるほど。
私は所持していないのですが、
Strutsタグについての解説が良いと
噂で聞きました。

引用:

そこには
設計のポイントとして
LookupDispatchActionの各メソッドに通常のActionクラスの
executeメソッドと同様の処理を記述することができる。
しかしそのように実装してしまうと本来は複数のActionクラスに
分割するべき処理を一つのActionクラスに実装することになり
メンテナンス性が低下してしまう。
LookupDispatchActionでは振り分け処理のみを行い、
実際の処理は別のActionを定義して実装する設計を推奨しています。

とありました。

これは私の本に書いてあったことと
表と裏の関係ですね。
状況によって判断し、使い分けるのだと理解しました。

引用:

同じ名前の複数のサブミットボタンがある場合というのを
具体的に例を示してもらえないでしょうかm(__)m?
--------------------
botton.update = 追加
botton.update = 更新
--------------------
botton.add = 追加
botton.insert = 追加
こんなパターンでしょうか??


リソースバンドルファイルではなく、
HTMLフォームのサブミットボタンの名前です。
コード:
<html:submit property="action">
   <bean:message key="button.checkout">
</html:submit>
<html:submit property="action">
   <bean:message key="button.saveorder">
</html:submit>

のようなケースです。

引用:

戻るボタンなどの場合は,Validatorを使っている場合だと
戻るボタンを押下した時にも、入力チェックが走ってしまい
入力項目に正しい値を入力していないと
戻るボタンを実行することができないいう話を聞いたことがあります。

これは、ブラウザの戻るボタンを押した場合、
戻り先ページのValidatorチェック(JavaScript)が
実行されてしまうということでしょうか。

引用:

そこで戻るはJavaScriptで記述し
JSPのformタグ内にいれないようにすれば解決できるらしいですね。

これもどういう意味でしょうか。

コード:
function goBack() {
   history.go(-1);
}

<html:form>
・・・
   <a href="JavaScript:goBack">戻る</a>
・・・
</html:form>

とすれば、解決できるということ？
でも、ブラウザの戻るボタンを押したら？

うーん、実験してみようかな。
1

スキルアップ／キャリアアップ（JOB@IT）