- PR -

Steutsクラスの作り方

1
投稿者投稿内容
ジン
ベテラン
会議室デビュー日: 2007/07/27
投稿数: 52
投稿日時: 2008-05-23 09:27
現在Strutsでシステムを作ろうとしております。

Struts1.29
tomcat5.5
jdk1.5

Java経験者無しのチーム（自分が少々・・）でスタートし
現在設計段階で、クラスの作り方で迷っております。

現在の方針では・・

アクションクラス
→①画面毎？、②処理毎？
　①画面毎ですと登録・更新・削除などの複数の機能を持つ画面では
　　アクションクラス内で分岐が多くなってしまします。
　②処理毎ですと似たようなクラスが複数できてしまいますし
　　クラスファイルが膨大になります。
　
　また表示クラス・処理クラスを分け、そのクラス間を
　リダイレクとしてPRG方式も考えております。

フォームクラス
→①画面毎？、②入力用と出力用？

ロジッククラス
→①画面毎、②処理毎
　これは処理毎と思っていましたが・・・
　画面毎にアクションクラスを作った時にはロジッククラスにも
　複数の処理を持たせるのか？と思いまして。

DTOクラス
→①画面毎、②処理毎
　ロジッククラスと同じ

基本となる考え方で
これらをしっかり決めておかないと後々大変なことになるかと思いまして参考になる意見が聞きたく思います。
上記の現在方針は無視した意見も教えていただけたらと思います。
よろしくお願いいたします。
Gio
ぬし
会議室デビュー日: 2003/11/28
投稿数: 350
お住まい・勤務地: 都内から横浜の間に少量発生中
投稿日時: 2008-05-23 11:08
この辺りは、ジンさんが携わるプロジェクトのアーキテクト職位の方が検討・決定すべき事項かと思いますが、あくまでご参考の一つということで回答いたします。

以下、私がアーキテクトとして携わったプロジェクトでの実例を述べます。
決してこれがベストという訳ではありませんので、その点は誤解なきようお願いします。

・Action クラス群
画面毎。ただし 1 画面で種類の異なる機能が混在する場合は、種類毎に分ける。

機能が複数と言えども、10 個を越えることは稀でしょう。
（もしそうでない場合は、画面機能設計に問題があるかもしれません。）
CRUD (Create/Refer/Update/Delete) 程度であれば、if 文の連鎖で分岐したとしてもたかが知れています。
この場合は CRUD をまとめて 1 種類と数えていますが、種類が異なる機能がある場合は分割した方が良いと考えます。（後述）

・Form クラス群
一画面で入出力が混在する場合は、入出力で分ける。

例えば、検索条件を入力して検索し、その結果を表示する処理を考えます。
この時、検索条件 Form と検索結果保持 Form を同一クラス（画面毎の場合）とするか別クラス（入出力別）は設計時の決定事項です。
私が設計した時には、役割の異なる情報を 1 クラスに詰め込まないというポリシーを適用して別クラスとしました。
（このため、画面上部で検索条件を入力、下部で結果を表示する画面では、JSP 1 ファイルで 2 Form を参照する処理になります。）

他のポリシーとして、画面と Form を一対一対応にするというものも考えられます。
この場合は同一クラスとなるでしょう。
（検索結果にボタンを付け、ボタンがクリックされたら詳細を表示という処理も普遍的に多く見られると思いますが、このような場合は画面と Form を一対一対応にすると Action もそれに引きずられ、一つの Action クラスで検索と詳細照会を処理する必要があります。
私はこれを良しと判断しませんでしたが、この辺りはアーキテクトのバランス感覚（うがった言い方をすれば美意識）によると考えます。）

・ロジッククラス
処理毎。

同じ機能を画面毎に実装する必要性を感じません。
もっとも、ほぼ同じ機能でありながら、呼び出し元の画面により微妙に引数の数や種類が変わるというものはありました。
これはロジッククラスで対応する機能を複数用意することで対応しました。

・DAO クラス
データ表現クラス毎。

これもプロジェクトにより色々なポリシーがあると思います。
例を挙げます。

(1) データ表現クラスはテーブルと一対一対応とし、複数のテーブルを扱う操作は、データ表現クラスに基づいてロジッククラスで対応する。
(2) データ表現クラスはテーブルと一対一対応とする。複数のテーブルを扱う操作はロジッククラスで対応するが、必要に応じて DAO レイヤを介さず、直接 SQL を発行することを認める。
(3) データ表現クラスはテーブルに準ずるが、複数テーブルを扱う場合は、対応するデータを表すデータ表現クラスを別個設ける。ロジッククラスが DAO レイヤを介さずに直接 SQL を発行することは認めない。

(1) ではパフォーマンスの問題があるので却下しました。
（トランザクション管理がしっかりできていないと、データ参照の原子性(atomicity)の破壊という重大問題も発生します。）
(2) ではこの問題はありませんが、Action-ロジック-DAO というレイヤ構造を決定した意味がありませんので、これも却下です。
結局、重大な問題がなく、レイヤ構造も保たれていて、保守性にも問題がない (3) の方法を採りました。

テーブル T_A、T_B があった場合、対応するデータ表現クラス ClassA、ClassB を設けますが、T_A と T_B の特定条件 JOIN 結果が必要な場合は、テーブルに一対一対応しない ClassAB を設けます。
JOIN 結果を取ってくる操作はメインとなるクラスに応じて DaoClassA ないし DaoClassB に持たせても構いませんが、前述プロジェクトでは DaoClassAB を設け、ClassAB データの取得メソッドは DaoClassAB に持たせました。

この方法では JOIN 対象のバリエーションの増加に連れて Dao クラス群が増大するので、バリエーションが豊富であることがあらかじめわかっている場合にはお勧めできません。
このようなケースでは、多少無理があっても合理的である範囲で DaoClassA や DaoClassB に ClassAB データ取得メソッドを持たせてしまう設計もアリと考えます。

[ メッセージ編集済み 編集者: Gio 編集日時 2008-05-23 11:13 ]
ジン
ベテラン
会議室デビュー日: 2007/07/27
投稿数: 52
投稿日時: 2008-05-23 13:35
Gioさん丁寧にありがとうございます。
アーキテクト職位の方は
アクション・ロジック・フォオーム・ＤＡＯ・ＤＴＯに分ける方法を理解してもらうのにも時間がりオブジェクト指向の考えも分かってもらえません。
そこでここ辺りは任せてもらおうかなと思ってます。
参考にしてサンプルを作ってみようと思います。
ありがとうございます。
Gio
ぬし
会議室デビュー日: 2003/11/28
投稿数: 350
お住まい・勤務地: 都内から横浜の間に少量発生中
投稿日時: 2008-05-23 23:35
Web アプリケーションのフレームワーク構成くらい理解していないとアーキテクトとは呼べないと思いますが(^.^)←独断
# もっとも、システムすなわち Web アプリケーションという訳でもありません。
# 他のシステムでは相応の経験を積まれた方かもしれません。

それはさておき、重要なのはどのように構成すると処理の見通しが良く、修正が発生した時を影響範囲を特定できるかという観点です。

ジンさんの質問を拝読した限りですが、要点の抽出と候補の洗い出しは出来ているとお見受けしました。
私には応援程度しかできませんが、頑張ってください。
1

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