WPFControlTemplateとUserControl
最近、serControlを作成しましたが、カスタムの依存関係プロパティなどを操作する必要があったため、かなり時間がかかりました...
とにかく、TextBox、Popup with HierarchicalTreeの3つのコントロールの集まりでした。
今、私はおそらくControlTemplateのみを書くことができることに気づきました。したがって、serControlを使用する利点は何ですか？
ここで考慮すべき3つのケースがあります：UserControl、ControlTemplate、およびcustomControl。 （DataTemplateは説明を必要としないと思います）
カスタムコントロールは、新しいUIコンポーネントの基本機能を作成するときに提供するものです。これにはさまざまな長所と短所がありますが、たとえば、ItemsControlのカスタム選択動作が必要な場合は、SelectorまたはMultiSelectorをサブクラス化することで最適に実行できます（wpftoolkit DataGridがこれを実行します）。また、新しいDependencyPropertyを含むオブジェクトが必要な場合は、ほとんどの場合、Controlから派生します。
ここに含まれているwpfの原則は、「見た目が悪い」コントロールパラダイム、つまり「誰かがコントロールをテンプレート化することを期待するか、少なくとも独自のテンプレートシナリオで適切に動作させる」ことです。カスタムコントロールは通常、再利用性を念頭に置いて作成され、多くの場合、フレームワークdllの一部として作成されます。
ControlTemplateは、基本的に置換ビジュアルツリーの説明であり、FrameworkElementsで明示的に設定することも、スタイルの一部として設定することもできます。これは、主にアプリケーションを作成してそれを実行することが目標である場合に目指すべきオプションです。バインディングとトリガー（およびスタイル自体を含む可能性がある）を正しく取得できれば、ControlTemplateを使用して視覚的にほとんどすべてを行うことができます。これはすべて、再利用されるリソースとして宣言して、アプリケーションに共通の「テーマ」を与えることができます。
UserControlは、デザイナで個別に編集可能なパーツを備えた自己完結型の複合コントロールであり、コンポーネントを表示して管理する必要がある場合に最適です。デザイナーで。一方、ControlTemplateは、デザイナで操作するためにそのコンポーネントを公開しません（ただし、表示されます）。通常、顧客の詳細ページ、製品表示ブラウザ、または本格的なコントロールを作成したくないが、完全な設計者サポートを備えた詳細ビューが必要な場合は、UserControlを作成します。
ここでの特別なケースは、 [〜＃〜] mvvm [〜＃〜] パターンを使用する場合です。多くの優れたMVVM実装では、UserControlsをビューとして使用し、ControlTemplatesとStylesをそれらのビューで使用されるリソースとして使用します。 MVVMの実践は、カスタムコントロールの必要性を最小限に抑え、他にも多くの利点があります。
（MVVMの詳細については、とりわけ、Google for Josh Smith、Sacha Barber、Karl Shifflettの素晴らしい記事）
独自の依存関係プロパティを追加する場合は、それらを定義するための独自のクラスが必要になります。
テンプレートをクラスに適用する場合、このカスタムクラスはControlから派生する必要があります（UserControlと同様）。
独自のControl派生クラスを作成する主な利点は、アプリ内で、またはそのタイプの他のユーザーが、他の使用シナリオ用にテンプレートを再定義できることです。
UserControlクラスを使用する際のオーバーヘッドはほとんどありません。実際、Reflector.NETで見ると、コードがほとんどないことがわかります。主に、UserControlは、いくつかの既存の依存関係プロパティのメタデータを再定義するだけです（たとえば、デフォルト値をFocusablePropertyfalseにします）。
コントロールのテンプレートをすぐに再定義する必要がない限り、今のところはUserControlのままにして、必要に応じて後で変更できます。