Q&A
質問者さん、レスがついているのでそれに対するフィードバックを書きましょう。無言で放置は NG です。
#はじめに
お世話になります。
色々調べてはみたのですがはっきりとした結論が出せなかった為、相談させて頂きます。
どうぞ宜しくお願い致します。
#質問内容
おそらくはvb.netに限った話ではないと思うのですが、Form上に貼り付けたコントロールをデザイナ上で設定するのか、コード上で設定するのかでどちらが良いのか判断がつかない状態です。
おそらくどの方も使い分けをされているであろうと思っているのですが、どのように使い分けをされているのか、基準などありましたら教えていただきたいです。
#現状
- コントロールの名称、サイズ、色など、「外から見て分かるもの」についてはデザイナ上で設定
- TabIndexやEnable等の「外から見て分からないもの」や、DataGridView等の複雑な設定を必要とするものは極力コード上で実装
#本件に関する現状の認識
◆コード上で実装すると…
- 何をどう設定したのかが分かりやすく保守性が高い
- 設定読み込み分の時間が余計にかかる
◆デザイナ上で実装すると…
- ノンコーディングで実装できる
- どこをどう設定したのかが分かりにくい
以上、どうぞ宜しくお願い致します。
#ベストアンサーについて
お二方とも大変有益な情報を頂き大変迷ったのですが（特にSurferOnWww様のデータ絡みの解説は物凄く参考になりました）、私の質問に関する直接的な答えとして、他の方が見た際に簡潔にまとめられていると思い、radian様の回答を選ばせて頂きました。
お二方とも本当にありがとうございました。
回答2件
0
コントロールのプロパティをデザイナ上で編集するか、コード上で編集するか
デザイナ（ウィザードを含む）で作れるものはデザイナで作るべきと思います。開発工数・保守工数の削減になりますし、ミスによる後戻り工数の発生も少なくなるはずです。初心者の方が自分の勉強のために自力でコードを書いてみるというようことなら話は別ですが。
具体例としては以下のチュートリアルをみてください：
チュートリアル : データベースへのデータの保存 (単一テーブル)
https://docs.microsoft.com/ja-jp/previous-versions/0f92s97z(v=vs.120)
このように Visual Studio のデータソース構成ウィザードを利用して型付 DataSet + TableAdapter を作って、それを利用してアプリを作ると、
DataGridview ⇔ BindingSource / BindingNavigator ⇔ DataSet / DataTable ⇔ DataAdapter ⇔ SQL Server
という構造のアプリが、ほとんど自分でコードを書くこと無しに作れます。
後者の記事では、「7. データ読み込み時の処理」以降でコードを書いていますが、コード画面で実装するのはこの例のようにデザイナ/ウィザードベースではできない部分だけにすべきと思います。
投稿2021/03/26 04:59
退会済みユーザー
総合スコア0
返信が遅れてしまい申し訳ありません。
立て込んでおりまして、ご回答を読む暇もありませんでした。
ご回答いただき、ありがとうございます。
やはりノンコーディングは時代の流れなのでしょうか。
私の務める会社では「コードで何もかもやってしまおう」という傾向が強く、それを疑問視したことが今回の質問の始まりでした。
ご紹介頂いたデータ周りの知識は、ざっくり知っている程度でした（なんと自社では未だにrecordsetのみを使っています）が、特に「10 行でズバリ !! 非接続型のデータ アクセス」は網羅的にまとまっており、大変参考になりました。
早速これを使って取り組んでみたいと思います。ありがとうございます。
> 私の務める会社では「コードで何もかもやってしまおう」という傾向が強く
組織のルールがあるなら、あなたかそれを変えることができない限りは、ルールに従うべきだと思います。ルールを変えることを組織のメンバーを納得させられる知識・見識などを身につけられるよう頑張ってください。
弊社は大変レベルが低く…。そもそも「ルール」と呼べるものはありません。
「コードで何もかもやってしまおう」という【傾向】しか存在しないのです。
ちょうど今、ルールを策定しようとしており、それにあたってどうするのが一番良いのかを考えている所でした。
>ルールを変えることを組織のメンバーを納得させられる知識・見識などを身につけられるよう頑張ってください。
はい、頑張ります。いずれSurferOnWwwさんのように、分からない人に教えてあげられる人になりたいです。ありがとうございましたm(_ _)m
0
ベストアンサー
基本的には、
- デザイナで設定出来る部分⇒デザイナ
- 設定ファイルやデータベースの値を元に変動する部分⇒コード
でやってます。
何でもかんでもコードで設定すると、他人が引き継いだ時にデザイナと実画面の差がありすぎて困惑するので。（ちょっとしたレイアウト修正ならデザイナですぐ直せますし）
ただし、イベントハンドラ等をコードで一括設定した方が効率がいいケース等、例外はあります。
投稿2021/03/26 04:32
編集2021/03/26 04:40退会済みユーザー
総合スコア0
返信が遅れてしまい申し訳ありません。
ご回答ありがとうございます。
デザイナで設計できる部分は出来る限りデザイナで設計するのが基本なのですね。
あまり厳密にルール決めするのではなく、その場その場で柔軟に、といった感じでしょうか。
コントロールがたくさんある場合などは、イベントハンドラ等をコードで一括設定した方が効率がいい気がしてます。
参考になりました。
ありがとうございますm(_ _)m
> ・コード上で実装すると…
> 何をどう設定したのかが分かりやすく保守性が高い
と書かれていますが、デザイナの方が基本的に保守性は高いと思います。誰がやっても何を設定してるか自明ですし、デザイナを通す事でコードの出力も共通化されるので。
自前のコードで設定してる場合、どうしてもそのコードを確認するという一手間が発生してしまうんですよね。コードが長くなってくると、これがとても面倒になります。仕様書で決められているとしても、まず仕様書を読み解く必要が出てきますし。他のプロジェクトのソース引き継いだ時に、実際それで手間取った経験がそれなりにあります。
> ・コード上で実装すると…
> 何をどう設定したのかが分かりやすく保守性が高い
＞と書かれていますが、デザイナの方が基本的に保守性は高いと思います。
→ものすごく言葉足らずで申し訳ありません。より正確にお伝えすると、デザイナ上だと「一覧性」に欠けるところがあるのかなあ、と思っています。例えば沢山のコントロールがあり、それらに共通の設定をしてあげたい等といった場合に、デザイナ上でちまちまと一つ一つに設定するよりは、コード上で一律に設定した方が視認性や保守性は高いかもしれないというのが私の認識です。（共通の設定を変更したい場合は、置換してあげれば一発で変更できますし…。）
しかしコードをいちいち確認するよりもデザイナ上で確認できるほうがスマートなのかな？と今は感じています。
>例えば沢山のコントロールがあり、それらに共通の設定をしてあげたい等といった場合に、デザイナ上でちまちまと一つ一つに設定するよりは、コード上で一律に設定した方が視認性や保守性は高いかもしれないというのが私の認識です。
同じような設定をちまちま適用するくらいなら、継承コントロールやユーザーコントロールを作成しましょう。フォームも継承が可能ですので、同じようなフォームがいくつかある場合は、基本フォームを作って派生させると楽です。
[方法 : 既存の Windows フォーム コントロールから継承する]
https://docs.microsoft.com/ja-jp/dotnet/desktop/winforms/controls/how-to-inherit-from-existing-windows-forms-controls?view=netframeworkdesktop-4.8
こういったちまちまとした設定を行う場合でも、継承コントロールやユーザコントロールを使用するのですね。機能追加などを行う場合に使用するイメージでしたが、よくよく考えてみればその方がわかりやすそうです。頭の整理がつきました。大変助かりました。ありがとうございますm(_ _)m
あなたの回答
tips
プレビュー
