SAStrutsを利用したアプリ開発におけるコーディング規約

SAStrutsを利用したWEBアプリケーション開発を行う際に、私が利用しているコーディング規約の1つをご紹介します。 今回ご紹介するコーディング規約は以前に書いた記事「StrutsでWEBアプリを作成する際の基本クラス設計」の考慮も含んだものになっています。

前もって断っておくと、「SAStrutsを利用した」と一言で言っても、プロジェクトによって Action クラスにおける責務、Service クラスにおける責務 などは違う事がありますし、プロジェクトが大規模になれば更に新しいカテゴリとなるレイヤークラスを作成することもあります。 そういう意味で下記を読んで、「なんだ私がやっている今のプロジェクトにはマッチしないな」と思われる場合も多いと思います。 あくまでも一例として参考程度に読んで頂ければと思います。

それでは、さっそく書いて行こうと思います。

WEBサイト全体に関する画面遷移規約

• ブラウザの再POSTのアラートに考慮し、POSTアクセスを必要とする画面遷移はPRGパターンにより実装を行うこと。

クラスの役割に関する規約

Interceptor

• Actionクラスよりも上位(＝ServletFilterに近い位置・役割)のInterceptorを設置する場合、Interceptorの処理の中にビジネスロジックを書いてはならない。 あくまでもActionクラスよりも上位で行うべき共通処理を書くべきである。 Actionよりも下位で行うべき共通処理は書くべきではない。

formクラス

• クラス名は「Form」で終わること。
• GETやPOSTの入力パラメータをマッピングするformクラスのクラス変数は、全てString型とすること。 String型以外で宣言すると、formオブジェクトへの代入(マッピング)時のキャストでNumberFormatExceptionなどの型違いによるキャスト例外が発生する場合があり、またその例外はActionクラスの処理が始まる前に発生してしまうため、ビジネスロジックでcatchできないためである。
• formオブジェクトをHTTPセッションに代入して保持してはならない。

actionクラス

• クラス名は「Action」で終わること。
• serviceクラスのオブジェクトから戻り値としてEntityオブジェクトが返却される場合、そのEntityオブジェクトをそのままJSPに渡してはならない。 必ずDTOやformオブジェクトに値を詰め替えてからJSPに渡すこと。
• Actionクラスがデータベースアクセスを伴う処理を行なってはならない。
• HTTPセッションへの値の代入や参照は、基本的にはActionクラスの責務とする。 (※InterceptorやFilterでアクセスの必要がある場合は、その操作を許す。)

serviceクラス

• クラス名は「Service」で終わること。
• ServiceクラスがHTTPセッションのデータの取り扱い(参照や代入)を行なってはならない。
• serviceクラスに対するメソッドの呼出の引数は、必ずServiceクラスに対するServiceRequestクラスを継承したクラスとする。また、戻り値はServiceResponseクラスを継承したクラスとする。 (※補足・・・ServiceRequestクラス/ServiceResponseクラスは、独自のクラスです。 SAStrutsに元々ある概念ではありません)
• serviceクラスの処理にformクラスのオブジェクトを必要とする処理を記述してはならない。
• serviceクラスが画面遷移の際のURLやパスなどを決定してはならない。

entityクラス

• クラス名は「Entity」で終わること。
• entityクラスのクラス変数の型は、必ずクラス型でなくてはならない。 (＝プリミティブ型ではならない。)

以上が SAStruts に関してコーディング規約としていることです。 その他にも Java としてのコーディング規約も適用する場合があります。 そちらに関しては、また各自お持ちのJavaコーディング規約を適用して頂ければ良いと思います。

上記以外に「うちではこんな事も規約で守らせているよ」とか言うことがあれば、ぜひコメントしてください。