こんにちはゲストさん。会員登録(無料)して質問・回答してみよう!

解決済みの質問

Java Struts MVCモデル 正しい書き方

Java Struts1.3.10
皆でとあるシステムを作ることになったのですが、
JSP・ActionForm・Actionそれぞれの関係の在り方について悩んでいます。
ログイン機能を例とします。

1機能、1Form、1Actionとした場合は:
1.Login.jspでIDとPASSを入力。
2.LoginResultForm.javaにIDとPASSを格納。
3.LoginResultAction.javaでDBチェック(IDとPASSの存在・権限)
4.Result.jspへ遷移。ID・PASS・権限を表示する
使用するファイルは4つとなります。

1JSP、1Form1、Actionとした場合は:
1.Login.jspでIDとPASSを入力。
2.LoginForm.javaにIDとPASSを格納。
3.LoginAction.javaでDBチェック(IDとPASSの存在)
4.ResultForm.javaにIDとPASSを渡す(Sessionなど)
5.ResultAction.javaでDBから権限を取得、ResultFormに格納
6.Result.jspへ遷移。ID・PASS・権限を表示する
使用するファイルは6つとなります。

現在意見が三つありまして、

1.違うForm同士にデータのやり取りが発生するようであれば(1機能とし)、同じフォームにするべきではないのか?

2.Fromのメンバの数が少ないうちは良いが、今後数が増えると可読性が悪くなるから分けるべきではないのか?

3.フォームは同じでないとまずいが、ActionはJSPごとに分けるべき

というものです。
1.ではログイン者情報をセッションに保持することは許可しています。(一部例外を認めている)

これらはいずれもStrutsフレームワークの範疇から逸脱している、あるいはMVCモデルに反している、そもそも非効率的ということはないのでしょうか?

つまりあくまで実装の仕方の問題でしかない、という結論でよろしいでしょうか?

投稿日時 - 2009-11-26 17:21:05

QNo.5477873

暇なときに回答ください

質問者が選んだベストアンサー

あまりMVCとは関係ないような・・・。

機能の範囲はどの程度ですか?
例えば
1.データの一覧表示
2.データの詳細表示
3.データの登録
4.データの登録内容確認
5.データの修正
6.データの修正内容確認

とあった場合、1~6で1機能ですか?
もしくは
1、2~6で1機能
1、2、3~4、5~6で1機能

例えば1~6で1機能だとしたら「2.Fromのメンバの数が少ないうちは良いが、今後数が増えると可読性が悪くなるから分けるべきではないのか?」だと思います。

1、2~6で1機能
1、2、3~4、5~6で1機能
なら利用するフィールドはほぼ同じなので、「1.違うForm同士にデータのやり取りが発生するようであれば(1機能とし)、同じフォームにするべきではないのか?」、「3.フォームは同じでないとまずいが、ActionはJSPごとに分けるべき」でいいと思います。

ActionとJSPは対になっているほうが見やすいと思います。

投稿日時 - 2009-11-27 12:56:51

お礼

回答ありがとうございます。
>あまりMVCとは関係ないような・・・。
Model、View、Controlをそれぞれ別な人が担当する場合、「2.Fromのメンバの数が~」では、Model(Action)が複数のフォームを参照すると再利用性の面から宜しくないのでは?
Actionクラスは複数のフォームを参照できないように出来ていましたので、

Aform objForm = (Aform) form; //引数からform(Aform)を取得
Bform.set(objForm .getID); //Bformは引数にないので解決できない

推奨されないのかなと思いました。

>1~6で1機能ですか?
例であればそうなります。
基本、データの受け渡しが発生するものを1機能と定義することにしています。(ログイン者情報などはグローバルなものは別)

>ActionとJSPは対になっているほうが見やすいと思います。
ありがとうございます、Actionクラスは画面ごとに用意することにします。

投稿日時 - 2009-11-27 14:16:09

このQ&Aは役に立ちましたか?

2人が「このQ&Aが役に立った」と投票しています

回答(4)

ANo.4

>汎用的なBeanは、あらかじめどんなメンバが存在するかわかっていなければ作成できません。(わかっていることが前提であれば以下は無視して下さい)

>つまり一覧画面だけ別なシステム(DBは同じ)で再利用しようと考えた時
とあったので汎用的なBeanを利用するのかと思いました。


以下は汎用的なBeanのたとえですので無視してもかまいません。
汎用Beanは一覧画面の各レコードの情報を保持するためのBeanです。

一覧画面
選択|名前  |種別 |値段
○ |ホタテ |海産物|200
○ |アワビ |海産物|250
○ |国産牛肉|肉類 |2000

詳細画面
名前  |ホタテ
種別  |海産物
値段  |200
生産方法|天然
生産者 |山田太郎
登録日 |2009/11/30


汎用的なBean(ListBean.java)には以下のような種別に関係無いフィールドをもちます。
private int id;
private String neme;
private String type;
private int money;


一覧画面のFormクラスには以下のようなフィールドを持たせます。
private List<ListBean> list = new ArrayList<ListBean>();

このようにすれば別システムでの再利用も可能です。

投稿日時 - 2009-11-30 22:36:30

お礼

回答ありがとうございます。
ようやく理解出来てきた気がします。

一覧画面の構成が
ListAction.java
ListForm.java
List.jsp
ListBean.java
一覧画面と詳細画面のデータのやり取りはListBeanで行われる。

ListBeanの内容は、例ですと
id, name, type, money のみですので、遷移後詳細画面を表示するには生産方法・生産者・登録日が足りません。
これらは詳細画面のActionで、ListBeanの値を使用してDBから取得する、という認識でよろしいでしょうか?

投稿日時 - 2009-12-01 09:47:05

ANo.3

>この例の場合、フォーム数は4つということですね。
詳細画面、登録画面、登録内容確認画面、編集画面、編集確認画面で1つのFormを使いまわします。

>>private List<DetailsForm> list = new ArrayList<DetailsForm>();
>この内容のみ少々理解が及びません。
logic:iterateで一覧の表示を行うためです。

>ListForm.javaがDetailsFormという別フォームの型を意識してしまうと、互いの結合度が高くなるのではないかという意見が出ました。
この一覧画面と詳細画面のみで(一機能として)考えれば、結合度が高くなってもかまわない気がします。

>つまり一覧画面だけ別なシステム(DBは同じ)で再利用しようと考えた時、DetailsFormが関わる部分を書き換える手間が発生してしまうのでは。
他の部分でも使用するのならば、汎用的なBeanを作成して置き換えてもいいと思います。

投稿日時 - 2009-11-30 12:26:31

補足

以下
もし「汎用的なBean」が主キーを格納するもの、という意味で使用されていたのであれば
>汎用的なBeanを作成して置き換えてもいいと思います。
に関しては問題ありません。

失礼しました。

投稿日時 - 2009-11-30 15:07:43

お礼

何度目かのご回答、本当にありがとうございます。
また理解が足らず申し訳ありません。

>詳細画面、登録画面、登録内容確認画面、編集画面、編集確認画面で1つのFormを使いまわします。
ということはListForm.javaとRegistForm.javaで2フォームですね。

>logic:iterateで一覧の表示を行うためです。
理解できました、ありがとうございます。

>この一覧画面と詳細画面のみで(一機能として)考えれば、結合度が高くなってもかまわない気がします。
成程、どこからどこまでを一機能として考えるかが問題なんですね。

>汎用的なBeanを作成して置き換えてもいいと思います。
申し訳ありません、ここだけ理解が及ばないのですが。
宜しければ主キーを渡すのではなく、汎用的なBeanを作成する理由を教えていただけませんでしょうか。
汎用的なBeanは、あらかじめどんなメンバが存在するかわかっていなければ作成できません。(わかっていることが前提であれば以下は無視して下さい)

例えば
現時点では食品一覧画面→詳細画面となっていたものを、ユーザーの要望で。
海産物一覧→詳細
肉類一覧→詳細
と分けることになった場合。
一覧画面JSPは変更しませんが、詳細画面JSPに海産物のみ「天然or養殖」の項目が追加されたとします。
その場合、汎用Beanに「培養種類」などのメンバを加え、一覧画面のActionに汎用Beanの培養種類を設定する処理を書き加える必要が出てきてしまいます。

長々と何度も申し訳ありません。
何分Java・Struts共に不慣れなため、勝手が理解できず戸惑っている部分が多々あります。
実際の開発現場ではここまでの仕様変更は考慮する、しないなどの点もあるのでしょうが、その点も含めご指摘いただければ幸いです。

投稿日時 - 2009-11-30 15:05:58

ANo.2

以下は私が最近作ったアプリケーションの構成です。

一覧画面
1Action、1Form、1JSP

詳細画面、登録画面、登録内容確認画面、編集画面、編集確認画面
各画面は1Action、1JSP
フォームは共通のフォーム

一覧画面はその他の画面とは表示項目が異なるので別のフォームを作成しました。

一覧画面
ListAction.java
ListForm.java
list.jsp

詳細画面
DetailsAction.java
DetailsForm.java
details.jsp

登録画面
RegistAction.java
RegistForm.java
regist.jsp

登録内容確認画面
DetailsRegistAction.java
RegistForm.java
detailsRegist.java





こんな感じです。


ちなみにListForm.javaには
private List<DetailsForm> list = new ArrayList<DetailsForm>();
というフィールドがあります。

投稿日時 - 2009-11-27 22:10:37

お礼

ありがとうございます。
回答が遅れ、申し訳ありません。
色々話し合った結果をお伝えします。

>フォームは共通のフォーム
この例の場合、フォーム数は4つということですね。
同一の機能であり、かつ画面の表示項目が同じ(あるいは近似)ものに関しては同一Formにしていると理解しました。
これを参考にして設計を始めたいと思います、ありがとうございます。

>private List<DetailsForm> list = new ArrayList<DetailsForm>();
この内容のみ少々理解が及びません。

一覧画面:
1.DBから一覧を取得、表示
2.選択された内容の主キーをセッションで詳細へ渡す
詳細画面:
1.渡された主キーからDBよりデータを取得し表示

という形になると思うのですが。

ListForm.javaがDetailsFormという別フォームの型を意識してしまうと、互いの結合度が高くなるのではないかという意見が出ました。
つまり一覧画面だけ別なシステム(DBは同じ)で再利用しようと考えた時、DetailsFormが関わる部分を書き換える手間が発生してしまうのでは。
というものです。

投稿日時 - 2009-11-30 09:29:21

あなたにオススメの質問