C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[2]: データベースへの登録、更新、削除処理を作るに際して

(過去ログ 26 を表示中)

[トピック内 14 記事 (1 - 14 表示)]　 << 0 >>

■11926 / inTopicNo.1)

　データベースへの登録、更新、削除処理を作るに際して

□投稿者/ 柊 (4回)-(2007/12/25(Tue) 14:52:53)

分類:[設計/仕様]　

2007/12/25(Tue) 14:53:24 編集(投稿者)

柊です。
先日は貴重なアドバイスありがとうございました。
検索部分の問題が解決できたので次の処理を作ろうと作業中ふたたび躓いてしまいました。

いま作っているアプリでは、アプリでは最初の画面でDataGridViewを利用した一覧表を表示し
メニューで、「登録」「更新」「削除」を選択するように考えています。

いずれの画面も同じ画面構成で、新規の場合は、項目を空白にして表示し、更新、削除の場合には
選択されたデータを表示させようと考えています。

この時点で悩んでいるのですが、

１．画面構成が同じなので、１つフォームで登録の場合は更新の場合は･･･と、処理を分岐して書くほうがよいのか
２．処理毎にフォームを用意し、それぞれのフォームで処理を書くほうがよいのか

どちらがいいのかな？と悩んでいます。

アドバイスを頂ければ幸いです。

よろしくお願いいたします。

引用返信 編集キー/

■11927 / inTopicNo.2)

　Re[1]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ 囚人 (270回)-(2007/12/25(Tue) 15:07:11)

処理の複雑さに依るので一概には言えませんが、変に共通化して条件に応じてゴニョゴニョするとワケが分からんコードになりがちなので、どちらかと言えば私は「分ける派」です。

引用返信 編集キー/

■11928 / inTopicNo.3)

　Re[2]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ BAW (10回)-(2007/12/25(Tue) 16:06:44)

仕事でやっておられるなら、後々メンテナンス・改修等を行う場合、あなたがやるとは限りません。

私の場合、囚人さんも仰っておられるとおり、ややこしくなりがちなため
分けることをおススメします。

#だからって可読性が良くなるかどうかって別の話なんですけどね。

引用返信 編集キー/

■11929 / inTopicNo.4)

　Re[3]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ 柊 (5回)-(2007/12/25(Tue) 16:25:39)

■No11928 (BAW さん) に返信

> 私の場合、囚人さんも仰っておられるとおり、ややこしくなりがちなため
> 分けることをおススメします。

囚人さん、BAWさん　レスありがとうございます。
処理を分ける方向で考えてみたいと思います。
ありがとうございました。

引用返信 編集キー/

■11946 / inTopicNo.5)

　Re[1]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ やじゅ (40回)-(2007/12/26(Wed) 00:58:36)

■No11926 (柊さん) に返信
> 2007/12/25(Tue) 14:53:24 編集(投稿者)
>
> １．画面構成が同じなので、１つフォームで登録の場合は更新の場合は･･･と、処理を分岐して書くほうがよいのか
> ２．処理毎にフォームを用意し、それぞれのフォームで処理を書くほうがよいのか
>
> どちらがいいのかな？と悩んでいます。

私なら１番です。
画面構成が同じなら、画面に項目の追加があった場合に、それぞれのフォームを直すんですか？
更新処理程度なら、処理分岐のみで充分かと思います。

引用返信 編集キー/

■11954 / inTopicNo.6)

　Re[2]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ Pandora (33回)-(2007/12/26(Wed) 11:02:58)

私も２番で分けますね。

共通な画面構成及び処理を基本フォームに持たせ、そのフォームから派生させ登録用、更新用．．と
フォームを作成すれば、追加 or 変更があっても基本フォームで吸収できると思います。

引用返信 編集キー/

■11966 / inTopicNo.7)

　Re[3]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ やじゅ (42回)-(2007/12/26(Wed) 12:49:16)

■No11954 (Pandora さん) に返信
> 私も２番で分けますね。
>
> 共通な画面構成及び処理を基本フォームに持たせ、そのフォームから派生させ登録用、更新用．．と
> フォームを作成すれば、追加 or 変更があっても基本フォームで吸収できると思います。
>

基本フォームって１機能ごとに作成するんですか？
得意先マスタ、商品マスタ、受注入力などがあった場合に、それぞれに基本フォーム作って処理ごとフォームを継承すると
フォームが結構な数になるし。
私が今まで作成してきた、基本フォームはファンクションバーとスタータスバーくらいにしておいて使用してます。

得意先マスタ
　登録-フォーム1　
　更新-フォーム2
　削除-フォーム3
商品マスタ
　登録-フォーム4　
　更新-フォーム5
　削除-フォーム6
受注入力
　登録-フォーム7　
　更新-フォーム8
　削除-フォーム9

引用返信 編集キー/

■11972 / inTopicNo.8)

　Re[4]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ 囚人 (273回)-(2007/12/26(Wed) 13:46:14)

あくまで場合に依るという事を前置きしておいて。

「画面の形が同じ」という理由でフォームを共通にし、「参照の場合はホゲホゲ、更新の場合はフガフガ」っていうのはちょっと違うと思うんですよね。共通化すべき単位が違うと言うか。

もしここで共通化を念頭に置くなら、「画面の形が同じ部分」をコントロールにしておき、参照用のフォームと更新用のフォームに貼り付けてそれぞれのフォームでロジックを書くのが良いかなと思います。

基本フォームから継承ってのもあまり好ましくないと思いますね。

引用返信 編集キー/

■11981 / inTopicNo.9)

　Re[5]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ Pandora (34回)-(2007/12/26(Wed) 14:37:56)

> 基本フォームって１機能ごとに作成するんですか？

　状況によると思いますが、提示された例を利用させて頂くと得意先マスタ基本フォームを
　作成し登録用、更新用、削除用と作成しますね。
　機能による処理の違いを、各フォームが吸収することになります。
　また、データベースにアクセスする情報等の共通な情報は、得意先マスタ基本フォームが
　吸収することになります。

　確かにフォーム数は増えますが、インスタンスを作成してしまえば条件による分岐はなく
　なるのでスマートかと思っています。

　何がスマートかは、見解の相違があると思いますが、私は１つのフォームで条件分岐で
　それぞれの対応をするよりはスマートだと思っていますので、そのような対応をしています。

> 「画面の形が同じ」という理由でフォームを共通にし、

　確かに「画面の形が同じ」という理由で対象機能や対象項目が違う場合は、そうだと思いますが、
　対象機能や対象項目が同じ場合は、問題ないと判断しています。

> 基本フォームから継承ってのもあまり好ましくないと思いますね。

　そうですかね。
　断定されてしまうと困りますが、そのような考えの人もいると理解しました。

引用返信 編集キー/

■11985 / inTopicNo.10)

　Re[6]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ 囚人 (274回)-(2007/12/26(Wed) 15:31:12)

>そうですかね。
>断定されてしまうと困りますが、そのような考えの人もいると理解しました。

断定するのは駄目でしたね。すみません。
「私は好ましくないと思います」と言いなおします。

>確かにフォーム数は増えますが、インスタンスを作成してしまえば条件による分岐はなく
>なるのでスマートかと思っています。
>
>何がスマートかは、見解の相違があると思いますが、私は１つのフォームで条件分岐で
>それぞれの対応をするよりはスマートだと思っていますので、そのような対応をしています。

は同意見です。１つのフォームで条件分岐するとややこしくなると思います。

共通化したいという名目で継承を使うのは誤りだと感じています。先にも言った通り、こういう場合はその部分だけコントロールにしてしまえばいいのです。

フォームにはっつけたただの部品なんて幾らでもコピーがあっていいんです。それで何が困るんでしょう。仕舞いには、一部だけ共通なんて事になり破綻します。
http://blogs.wankuma.com/shuujin/archive/2007/11/29/110910.aspx

上手くできればそれで良いですが、一番目に選ぶべき選択肢に「同じフォームの使いまわし」や「共通フォームの継承」はないと思います。

引用返信 編集キー/

■11987 / inTopicNo.11)

　Re[7]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ Pandora (35回)-(2007/12/26(Wed) 16:03:47)

> 共通化したいという名目で継承を使うのは誤りだと感じています。

　これは同意見です。

> 先にも言った通り、こういう場合はその部分だけコントロールにしてしまえばいいのです。

そういうときもありますね。

> http://blogs.wankuma.com/shuujin/archive/2007/11/29/110910.aspx

　継承と委譲についての内容ですね。
　記載されている内容には同意見です。

> 一番目に選ぶべき選択肢に「同じフォームの使いまわし」や「共通フォームの継承」はないと思います。

ドメインクラスみたいに継承での問題にまだGUI系で直面したことがないので、まだ同意見まではいきませんが
GUI系でもドメインクラスと同じような問題点が潜んでいることはあると思います。

もう少し改善がないか検討してみたいと思います。

ただ、少し脱線させたみたいで、質問者の方、どうもすみませんでした。

引用返信 編集キー/

■11996 / inTopicNo.12)

　Re[8]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ まどか (421回)-(2007/12/26(Wed) 17:40:40)

基底フォームについては、極めて大規模なものや操作性とGUIの統一、そして生産コストなどの観点では有効な場合がありますよね。
まぁ、好んでそっちの方向にばっかりいくのは問題ですが。

機能の共通フォーム化ですが、業務の性質によるところも大きいのでは。
たとえば、マスタメンテナンスなんてのはDBとほぼ等価であるので「DBの修正＝フォームの修正」が成り立ち
そういう意味では押し込めてもいいと思います。

あとは、分岐処理の内容がほぼGUI操作になるかどうかですかね。
Validator系のユーティリティ等により業務処理が抽象化されてたり、最終ボタンのSQLだけが違うとか。

引用返信 編集キー/

■12009 / inTopicNo.13)

　Re[1]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ 柊 (6回)-(2007/12/27(Thu) 09:35:21)

柊です。
みなさんの書き込みを読んでいるだけで大変勉強になりました。
基本フォームを作成してフォームを継承させる形で進めてみたいと思います。
ありがとうございました。

解決済み

引用返信 編集キー/

■12018 / inTopicNo.14)

　Re[2]: データベースへの登録、更新、削除処理を作るに際して

□投稿者/ 特攻隊長まるるう (109回)-(2007/12/27(Thu) 11:40:44)

■No12009 (柊さん) に返信
>基本フォームを作成してフォームを継承させる形で進めてみたいと思います。
って事は別画面？ってことは別クラス。。。

まず、要件定義という作業が必要で、業務の内容を調査した時点で、
登録ばっかり行う担当者と、更新ばっかり行う担当者と、
削除ばっかり行う担当者がいるなら別画面でもいいと思うけど、

一覧から検索して更新、無かったら登録とかいう流れで操作
するなら、別画面では使い難いのでは？

まぁ、一覧表と、登録、更新、削除画面が別で、一覧表の[登録]ボタンを
押したら[登録]ダイアログに1件分が表示されて、同様に[更新]ダイアログ、
[削除]ダイアログがあって、ダイアログのそれぞれが継承されたフォームと
いうならまだ分かるけど。

で、
>いずれの画面も同じ画面構成
の時点でフォームを継承する意味が無いと思います。登録、更新、削除
の違いを、結局のところ継承元に全部書くことになったりしませんか？。
もちろん、継承元はイベントを起こすだけで何も処理せず、各継承先で
違う処理を。。。とか理解してるなら。。。まぁ。。。悪くはないんでしょうが。

それにしても、それぞれの処理が、クラス単位で分けるほどのものには
感じません。プロシージャレベルで十分では？
各処理がそれほど冗長になるようにも思えませんし(10行程度では？)
ボクは、フォームまで別にするメリットを感じませんねー。

基本フォームに何を実装して、継承フォームに何を実装するという事を
明確にできないうちは、下手に新しい技術を使っても、無駄な処理ばかり
書いてしまう結果になりがちです。技術に振り回されて、動かすことが
できす、動くコードにするために冗長なコードを書いていた。これなら
素直に条件分岐で１つにまとめて書いた方が良かった。ということも
起こりえます。

あくまで、ここで難しい内容にまで踏み込んで回答をつける人は、それに
見合うだけの知識と経験を持っていることを忘れてはいけません。自分の
レベルも考慮に入れるべきです。

技術は手段です。技術論に走らず、先にシステムの目的や、条件、現状の
把握といったものをもう少しすべきでは？

解決済み

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可