home.csフォーム内のコードの量に制限やパフォーマンスのペナルティはありますか?
Visual Studio 2008 の C# でデータベース アプリケーションのフロントエンドを作成しています。状況に応じて、新しいフォームを使用する代わりに、エンド ユーザーに表示される情報を変更するタブ ページの方法を使用しています。
VBA/MS Access から来て、特定の行数のコードを超えると、エラーが発生してコンパイルされないことを覚えています。C# は Visual Studio 2008 でこれを行いますか? それとも、パフォーマンス ヒットが発生しますか? すべてが 1 か所にあるため、コードの可読性が問題になる可能性があることはわかっていますが、状況によってはそれが利点であると考えることもできます。
パフォーマンスに関して心配する必要があるのは、.cs ファイル内のコード行ではなく、問題を引き起こす可能性のある実行時のフォーム上のコントロールの数です。いくつかのタブ上のいくつかのコントロールだけであれば、問題はありません。多数のタブに何百ものコントロールがある場合、パフォーマンスの問題が発生する可能性があります (ユーザビリティの問題は言うまでもありません。個人的には、複数行のタブを持つタブ コントロールは嫌いです)。
また、UI の目的が、ユーザーがすべてのタブを連続して操作するウィザードのようなものである場合、タブは適切ではないと思います。タブは、すべてのオプションを一度に表示する必要なく、一連のオプションをユーザーに提示することを目的としています。
最後に、各タブの目的が大きく異なる場合は、機能の各ビットを個別のフォームとしてカプセル化する方が簡単であることがわかりました。タブを使用すると、少なくとも各ビットをユーザーコントロールとしてカプセル化し、フォームの各タブにユーザーコントロールの 1 つのインスタンスをホストさせることができます。
私が予見する唯一の問題は、将来的には維持するのが非常に難しくなることです.
そのメインフォームのロジックを可能な限りクラスに分割して、何かを追加する必要があるときに実際に適合せずにそれを実行できるようにしてください。
「すべてが 1 か所にあるため、コードの可読性が問題になる可能性があることはわかっていますが、状況によってはそれが利点になることもわかります。」
私の経験では、コードをモジュール化して、変更される可能性のある部分や、明らかに異なる目的を果たす部分を分離することは受け入れられている慣行であるため、この態度は、将来コードを保守しなければならない人に最終的にかなりの頭痛を残します。互いに離れています。
そうは言っても、ファイルの長さにVSによって課される制限があるとは思いませんが、ファイルが長くなると、特にデザインビューとコードビューを切り替えるときに、非常にイライラするパフォーマンスの低下に遭遇すると思います.
将来の自分自身とその正気を保ち、コードを論理的に別々のファイルに分割することを強くお勧めします。後で感謝します！
タブを使用している場合でも、タブに表示されるコンテンツを保持するカスタム ユーザー コントロールを作成できます。タブごとにコントロールを作成すると、異なるタブのコードを別々に保つことができます。MSDN hereのウォークスルーがあります。
タブを表示しないという上記のコメントに応えて、これにどのようにアプローチしているかを本当に考え直します. すべてのユーザー コントロールをメイン フォームに配置し、必要に応じて Panel に配置し、すべてを に設定してからDock = DockStyle.Fill、表示するものに基づいて Visible および Enabled プロパティを変更してみませんか? あなたはこれを必要以上に自分自身に難しくしているかもしれません.
コメントへのその他の回答 - Java の CardLayout のようなものを探しているかもしれません。GNU Classpath バージョンのソースはここにあります。これを実装する方法についていくつかのアイデアが得られるかもしれません。
それは問題ではないはずです。
適切なコーディング プラクティスを念頭に置いて、コードをモジュール化して読みやすさと保守性を高めてください。
一方、フォームに配置するコントロールが多すぎると、読み込みに時間がかかる可能性があります。きびきびとしたインターフェイスが必要な場合は、それを設計に組み込んでください。
恐ろしいように聞こえますが、それが問題になる理由がわかりません。
30,000 行を超える新しいジョブで継承されたフォームがあります。完全に癌です。コーディングしてモジュール化する前によく考えてください。