フォームはコントロールです(継承チェーンを見れば分かります)。フォーム自体はオーバーヘッドがあまりありません。これはネイティブウィンドウを作成しますが、それはそれです。
ソリューションにUI要素をどのように使用して表示するかは、どのような決定要因になりますか。フォームは多くのUIアーキテクチャーに役立ち、ほとんどの開発者がよく知っているものです。デザイナーはそれらをうまくサポートし、フォームを作成、表示、隠し、閉じていることはよく文書化されていてよく使われるパラダイムです。はい、それは含まれているコントロールのすべてを作成するようにフォームが作成されるたびに負荷のペナルティがありますが、UserControlの場合でもそれを支払うつもりです。どちらの場合でも子コントロールを作成する必要があります。
フォームでは毎回フォームを作成する必要がありますが、それは当てはまりません。 Closeの代わりにShowDialogまたはHideを使用すると、フォームを再利用して価格を一度支払うことができます。ここでの利点は、フォームがあなたのコントロールをあなたのために保持し、あなたのためにそのすべてを管理するので、GCを気にする必要がほとんどなく、生きている根を思い出すことです。
UserControlのパラダイムはより複雑です。メモリの負荷を低く抑えるために、自分でコントロールのロードとアンロードを管理する必要があります。複雑さはまた、維持コスト、サポートコスト、および開発コストの増加を招く。しかし、いくつかのシナリオでもUserControlsには明確な利点がいくつかあります。 MVC/MVPパターンとビューを扱うフレームワークを使用すると、USerControlはフォームがワークスペースになっている実際のビューを作成します(SCSF for the desktopはこれの古典的な例であり、OpenNETCF.IoC frameworkもCF用です)。
「これは良い」ですか?それは要素の使用方法と場所、チームがすでに開発を行っている方法、接続しているソリューションをどのように構築したかによって異なります。一言で言えば、正解は誰もいません。
ことがあるかもしれない理由はわかりません。フォームはコントロールから派生し、そのためにコントロール自体があります。それは単なるコンテナコントロールです。それは含まれている子供が建設中に多くの仕事をしない限り、それは実際にはほとんどオーバーヘッドを持っていません(それはフォームの誤りではありません)。 – ctacke
@ctacke私は何か非常に間違っていると言っているわけではありませんが、単純なテキストボックスを使ってForms vs. Controlsを使って比較しようとしました。同様の結果。具体的には、私たちのデバイスでは、previoiusフォームをクリアして、新しい完全なフォームを表示することに問題があるようです。私は、デバイスがはるかに小さな矩形を描画するだけで、以前のものを処分する必要がないため、速度が向上したと推測しました。しかし、純粋に推測する。 –