HTMLベースのWebアプリケーション開発で、画面を設計する際のベストプラクティスは
「GUIベースのアプリケーションとして考え」「それをJSPとActionに分離する」です。
こうする理由は、「本質的にService呼び出しが必要な箇所を洗い出すため」です。
ちょっと長めのエントリになりますが、この結論に至る経緯を説明していきます。
まず、GUIで画面を考えたら、
これをJSPとAction、Serviceに分離していきます。
もちろん、GUIの1画面は、1つのJSPファイルでは実現できない事がほとんどなので
複数のJSPファイルに分割して、「入力１」「入力２」「確認」「完了」など
ウィザード風の画面分割を行なっていきます。
ここで注意するのは、「GUIのクライアントで閉じた処理」（＝画面の処理）に相当する処理は、
JSPとActionで書ききる、ということです。
画面に関連する処理を、Serviceに書かないのが、1つのコツです。
よくある「Actionにはあまり処理を書くべきでない」という原則に従うと、
とにかくServiceに処理を投げすぎてしまって、
入力のバリデーション（フレームワークが自動でやれない複数項目バリデーションなど）を
Serviceに書いてしまったりもします。
でも、そうすると、本来Serviceでやるべき処理と、
そうでない処理の切り分けが、どんどん曖昧になってきます。
なので、ここで一つ、
「Serviceは画面やフレームワークを知るべきでない」という原則を投入します。
Serviceを呼び出すのは、
Strutsかも知れませんし、JSFかも知れませんし、Flexかも知れません。
あるいは、バッチから呼ばれるかも知れません。
Strutsにできないバリデーション処理をServiceに書いたりしても、
Flexにできないバリデーション処理とは内容が異なるため、
同じServiceを利用することはできません。
だから、Strutsから呼び出すのであれば、
Struts特有の処理はActionで行なうべきなのです。
つまり、GUIのクライアントのみで行なえる処理は、JSPとActionで書ききるのです。
こうしておけば、
もしWebサービス呼び出しが必要になっても、JSPとActionの代わりに
Webサービス呼び出しインタフェースクラスを作成するだけで良くなります。
では、いつActionからServiceを呼び出すかというと、
それは「GUIからサーバに通信するところ」です。
そう、この通信箇所を極力少なくするために、わざわざGUIで一度考えるのです。
GUIで考えれば「本質的にService呼び出しが必要な箇所」を洗い出すことが
比較的、直感的にできます。
もし、GUIの画面に「一度発注したことのある商品のドロップダウンリスト」を出すなら
このリストを出すためにServiceを呼び出す必要があるわけですから、
そんな箇所では、ActionからServiceを呼び出して構わないのです。
こうやっておけば、Serviceを先に設計する、という
グッドプラクティスとの親和性も高くなります。
