@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

登録画面と照会画面を共通的に実装しますか?

1
投票結果総投票数:24
共通的に実装する 7 29.17%
個別実装する 17 70.83%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、@ITは一切保証も関与もいたしません。
投稿者投稿内容
shin
会議室デビュー日: 2006/06/01
投稿数: 2
投稿日時: 2006-06-01 17:08
登録画面と照会画面を共通画面として実装するか否かという議論がプロジェク
ト内であり、私はなんとなく以下のような理由で個別の専用画面として実装す
ることを主張していますが、他のメンバーになかなか納得してもらえません。

何か良い具体例がありましたら、ご教授下さい。

「共通画面を検討する際には、極力シンプルな構造となるように考慮する。例
えば、登録画面と照会画面を共通的に実装するよりは、それぞれを個別の専用
画面として実装した方がシンプルであり、後々の問題が起きにくい。」
(http://www.plush.jp/tech_web/Technical_page_MVC_DetailDesign.htmlより)


●システムの特徴
・JSP + Struts
・画面数200〜300
・シンプルHTML ではあるが、一画面に含まれる項目数が比較的多い

●私が考えた個別実装する理由
・入力項目を読み取り専用にしたり、ボタンの表示・非表示を切り替えるとい
 ったロジックが発生する
 (難しくはないがプログラムの複雑さが増加し、JSP が煩雑になる)
・画面数が比較的多いので、やや複雑な登録兼照会画面を作成するより、シン
 プルな登録画面と照会画面を個別に実装するほうが、生産性の向上が見込め
 る
・登録画面と照会画面は、機能として独立しているため、プログラムモジュー
 ルも独立させたほうがよい(理由を説明しきれていていません。)
・詳細設計書に登録画面と照会画面の場合どのようにボタンやコントロールを
 制御するか記述する必要がある(詳細設計書が複雑になる、設計書の記述誤
 り、実装誤り、テスト誤りの可能性が増す)

●私が考えた共通実装する理由
・レイアウトの変更が発生した場合メンテナンス対象のプログラムモジュール
 が1つになる
ひろ@ya
大ベテラン
会議室デビュー日: 2006/02/23
投稿数: 168
投稿日時: 2006-06-01 19:32
登録と照会で想定されるユーザーが同じかどうか
使用頻度はどちらの方が高いか
画面遷移も同じに実装するべきか

といったところを検討することになるでしょうね。

また、JSPを共通化してHTMLの入力要素(input要素等)の属性値を登録/照会で
切り替える場合は、変更不可にするのに readonly ではなくdisabled を使う
必要がある入力要素(select, input type="radio"等)に注意が必要です。

これらをdisabledにすると、ブラウザにもよるかと思いますが、

(1)デフォルトの配色は灰色系の現在状態の視認性がかなり悪い色になる
(2)(1)の色をスタイルシートで変更できない場合がある

という挙動を示すので、デザイン及びユーザビリティ上の欠点になる可能性があります。

そこまで考慮して照会モードの時は本質的に編集できないHTMLタグを生成するタグライブラリを起こしてしまうという手もありますけど。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷        良回答(20pt)
投稿日時: 2006-06-01 22:21
引用:

shinさんの書き込み (2006-06-01 17:08) より:
登録画面と照会画面を共通画面として実装するか否かという議論がプロジェク
ト内であり、私はなんとなく以下のような理由で個別の専用画面として実装す
ることを主張していますが、他のメンバーになかなか納得してもらえません。


「個別の専用画面」って、要は2つ別々に作るってことであり、共通化しないってことですよね。
普通(と言っても私の思い込みもあるかもしれませんが)、こういう掲示板では、他のメンバーのかたがたのほうが個別派(共通化に反対)であり、掲示板で質問されるかたが非個別派(共通化に賛成)というケースが多いのではないかと思いますが、今回はその逆ですね。
モデルとビューの関係で捉えると、モデル重視だと非個別派になり、ビュー重視だと個別派になるのでは、と考えます。最初に Struts 等のフレームワークありき、という前提だと、自ずとビュー重視になり、したがって個別派に傾くのではないでしょうか。
私は、どっちかといえば非個別化のほうですが、ツールが自由に使えない(ツールに縛られる恐れがある)となると、ツブシが効く安全さを優先して、個別化のほうになってしまうかもしれません。

--
unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86}
会社員
ベテラン
会議室デビュー日: 2003/01/21
投稿数: 50
投稿日時: 2006-06-01 23:52
「専用画面」が正しいと思いますね。
理由としては、途中からHELPを入れやすい点ですね。
プロジェクトが遅れている場合や、メンバーの一人が交通事故等で長期離脱する例もあります。
納品後の保守もしやすいですね。
shin
会議室デビュー日: 2006/06/01
投稿数: 2
投稿日時: 2006-06-05 17:34
ひろ様、unibon 様、会社員様

ご返答ありがとう御座います。

説明不足でしたが、弊プロジェクトとしては、ひろ様のご指摘の割り切りは、
他のメンバー認識しており、ユーザ様にも恐らくご了承頂ける状況です。

個人的には、そのような状況であっても「専用画面」のほうがよいと考えてい
ますが、他のメンバーや、ユーザ様は、設計書やプログラムモジュールの数を
減らすことに効果を感じています。
他のメンバーも、一応は私の意見を聞き入れてくれていますが、本当に納得で
きていないので、ユーザ様に説明する自信が持てないといった状況です。

投票でもある程度意見が分かれているように、システムの特性やPJの状況に
よるのかもしれません。
或いは、乱暴な考え方ですが、「決め」の問題だけなのかもしれませんね。


どちらかが絶対的に正しいという意見でなくても、両者の長所短所など、お気
付きの点がございましたら、引き続き返信をお待ちしています。

会社員様から頂いたご意見は、プログラムの複雑さを排除することによる具体
的なメリットを求められたときに、拝借させて頂きます。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-06-05 17:41
Client アプリケーションであれば、照会画面 '自体を' 共通することはあります。(保守が楽なので)
Web アプリケーションの場合は、個別にすることが多いですね。(値の引き渡しの関係で保守がつらくなるので)

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
末記人
常連さん
会議室デビュー日: 2004/03/31
投稿数: 27
投稿日時: 2006-06-05 18:05
条件文が多ければ、多くなるほどバグの温床になってしまうかと(テストも面倒だし…)
項目増やすにしても、煩雑になった1画面を改修するより、シンプルな2画面を改修する方が絶対に楽なはず(というか楽)
1

スキルアップ/キャリアアップ(JOB@IT)