GUIを設計および実装するための何らかの体系的な戦略はありますか？
Visual Studioを使用して、C＃でGUIアプリケーションを作成しています。ツールボックスは気の利いたコンポーネントパレットとして機能し、ボタンやその他の要素（わかりやすくするために「コントロール」を意味する場合はボタンと呼びます）をフォームに簡単にドラッグアンドドロップできます。ただし、2つの問題が発生します。 そもそもボタンを作成するのは大変です。静的ではないフォームがある場合（つまり、ユーザーの操作に応じて実行時にボタンまたはその他のコントロールが作成される）、パレットをまったく使用できません。代わりに、使用しているメソッドでコンストラクターを呼び出して各ボタンを手動で作成し、ボタンの高さ、幅、位置、ラベル、イベントハンドラーなどを指定して手動で初期化する必要があります。フォームがどのように見えるかを確認することなく、これらのすべての化粧パラメータを推測する必要があるため、これは非常に退屈です。また、各ボタンに対して多くの行の反復コードを生成します。 ボタンに何かをさせるのも大変です。フル機能のアプリケーションでイベントを処理することは大きな苦痛です。私がこれを行う方法を知っている唯一の方法は、ボタンを選択し、そのプロパティのイベントタブに移動し、イベントをクリックしてOnClickイベントFormのコードを生成し、イベントの本文を入力することです。ロジックとプレゼンテーションを分離したいので、イベントハンドラーはすべて、適切なビジネスロジック関数の単一行呼び出しになります。しかし、これを多くのボタンに使用すると（たとえば、MS Wordなどのアプリケーションに存在するボタンの数を想像してください）、数Form十の定型イベントハンドラーメソッドでmyのコードを汚染し、これを維持するのは困難です。 これらのため、Hello Worldよりも複雑なGUIプログラムは、実際に作成するのは非常に非現実的です。明確にするために、最小限のUIを使用して作成するプログラムの複雑さを扱うことには何の問題もありません。ビジネスロジックコードをきちんと構築するために、かなりの能力を備えたOOPを使用できると感じています。しかし、GUIを開発するとき、私は立ち往生しています。とても退屈だと思うので、私は車輪を再発明しているように感じます。また、読んでいないGUIを適切に行う方法を説明する本がどこかにあります。 何か不足していますか？または、すべてのC＃開発者は、繰り返しイベントハンドラーとボタン作成コードの無限のリストを受け入れるだけですか？ （うまくいけば役立つ）ヒントとして、良い答えが語れると期待しています： OOP手法（ファクトリーパターンなど）を使用して、繰り返しボタンの作成を簡素化する 多くのイベントハンドラを単一のメソッドに結合し、Senderどのボタンがそれを呼び出したかを判断し、それに応じて動作する単一のメソッド XAMLおよびWindowsフォームの代わりにWPFを使用 もちろん、これらのいずれにも言及する必要はありません。どんな種類の答えを探しているのかということに関しては、最善の推測です。