DispatchActionに定義するメソッドはひとつか

DispacheActionと言えど基本概念はActionと一緒。1イベント、1メソッド、1クラスと。しかし、それじゃーDispatchActionの意味が無い。機能ごとに1クラスに複数メソッド書いても良いじゃないですか。例えばマスタメンテナンスなら、select, insert, update, deleteメソッドを定義するみたいな。ただし、これはメソッドが短い時のみ。1アクションで1000ステップも行ったらそりゃ間違いです。せっせせっせとイベントを小分けしたほうが良いでしょう。

DispacheActionの利点はメソッド名がexecute固定でなく、複数のメソッドを定義できる事。複数のアクションを一つのクラスで処理できる事だと思うので、例えばウィザードみたいな一連のイベントを処理する場合は、1ファイルに収まっていて分かりやすいと思うわけです。パッケージにまとめてクラスを小分けするんでも良いですけど、タブ開きすぎ(苦笑)

っとここまでは前文です。今やってるStrutsのコードは1イベントあたり20行程度のとーっても小さい実装に収まっています。多くても50行くらいかな。だから、機能ごとにひとつのDispacheActionクラスでもとても見渡しが良い。メンテナンス性が良くて、関連ある機能が見渡せるなら、小分けにしなくても良いなぁと実感した瞬間でした。

DispacheAction使うとstruts-configの肥大化も防げますしね。いや、肥大化とかの前にユースケースごとに分けてしまうという方法がありますが、それはそこそこの規模があってこそ。あまり大きな規模じゃない時は管理するファイルが増える分だけ面倒です。でも分業する時は便利なんですよね…CVSからアップデート＞コミットを連日やるのは面倒なので、あっちのチームとこっちのチームでstruts-config分けてしまおう！リリース前に統合ってことで。これでもOKなわけです。少なからずサブシステムごとには分けますが、機能ごとに分けなきゃいけないのは、ひとつの機能にさまざまな機能が凝縮している場合で、設計そのものを直す選択肢もあるかもしれません。今の所機能ごとにstruts-configを分けているのは遭遇したことがありません。臨機応変結果良ければ全て良し。いつでもこれでOKじゃないですけど、臨機応変な対応は重要です。型に捕らわれすぎて自分を変えないは良くない。っと正論化してみる(苦笑)