一般的に、私はカスタムコントロールを使用してコントロールをフォームに直接組み込むことを考えています。カスタムコントロールを使用してフォームの複雑さを管理する必要がありますか？
特に、私はいくつかの.netフレームワークコントロールを含む6つのタブを持つタブページを含むフォームを持っています。現在、私は自分のプロジェクトで6つのユーザー定義のコントロールを持っており、それぞれのタブページにドッキングしています。 I.コントロールを再利用することはできません。それ以外の方法では、10個のgridview、20個のボタン、6個の日付コントロールなどを含むフォームの複雑さを管理することができます。この複雑さを管理するには、これを良い方法と考えるか、プログラマーが に何が起こっているのか理解できるようにするために、他の選択肢が良いでしょうか？
カスタム/ユーザーコントロールへのこのようなページ分割は、パーツを再利用しなくても有用であると考えられます。これは、あなたが得られます。
しかし、あなたのコンポーネントが適切に名前が付けられ、グループ化されていない場合は、これが裏目に出ることがあるので注意してください、ひどく設計された、あなたは多くを使います動的な読み込み、良いAPIを提供していないまたは入れ子が深すぎる行く。私はそれがレガシーアプリで起こるのを見て、それはそのように役立たなかった。
もしうまく行けば、それだけの価値があります。経験の浅い/怠け者のチームメンバーでは、うまくいきません。
あなたの複雑さは何ですか？あなたが私に尋ねるなら、あなたが使用する方法としてusercontrolsを使うなら、あなたはもっと複雑になっています。コードの重複を防ぐには、ユーザーコントロールを使用する必要があります。基本的には、あなたのロジックをあなたのusercontrolに移し、あなたのロジックを複数のページに分けて、メインページのコードが少なくて済むようにしています。あなたが私に尋ねるなら、これはあなたの主な関心事ではありません。
画面のセクションのビューモデルまたはコントローラに複雑なロジックがある場合、これは有益なアプローチになります。それはあなたの全体的なフォームをより複合的なものにしています。ビューモデルおよび/またはコントローラのセクション/コントロールの背後にある機能を個別に開発し、それらを個別にテストすることができます。 ImrePの言うとおり、これは懸念の分離の線に沿っています。
ただし、フォーム上の別々のコントロール間に多くのやりとりがある場合、これは正しい方法ではない可能性があります。フォームのさまざまな領域に異なる動作/責任の領域がある場合は、かなりのUIが発生していることを前提に、分割が良い考えかもしれません。
各パッケージに基本的なコントロールが少なくて済み、コンポーネントを再利用する機会がない場合は、多少水が濁っているかもしれません。
あなたのチームの誰かにそれを見せて、それを説明するのにどれくらい時間がかかるかを確認するのがよいでしょう。それが直感的であるかどうかを知るには良いアイデアを得るでしょう。