これらのプロパティがUIElements(または他のWPF固有のオブジェクト)として入力されたと想像してください。UIElementsではないオブジェクトをコントロールにどのように追加しますか?
必要な情報を公開するWPFオブジェクトから派生したラッパーを提供する必要があります。ほとんどの場合、ラッパーはラップされるオブジェクトのToString()を呼び出すだけです。使用するほとんどの型がToString()の十分なデフォルト実装を提供するので、開発者にすべてのラッパーを作成させるのではなく、これを呼び出すのが理にかなっています。
次に、それらが何らかのインターフェースとして入力されたかどうかを想像してください。このインターフェースではできないことを伝えたい場合はどうしますか?唯一のオプションは、(a)開発者がフレームワークの制限に耐えているか、(b)Microsoftがインターフェイスを更新し、すでに作成されている既存のコードをすべて破棄することです。
また、MVVMのようなパターンを使用しているかどうかも検討してください。現在の設計では、ビューモデルで、WPFに関連付けられていないプロパティを公開できるため、最終的には、さまざまなテクノロジ間でコードをより再利用できるようになります。
最後に、プロパティを表すオブジェクトと、WPFがその情報をレンダリングする方法には違いがあることを忘れないでください。たとえば、 System.Stringなどのプリミティブ型を使用する場合、WPFはテキストブロックを作成し、textプロパティをToString()の結果に設定します。これにより、UIによって表示されるデータと、UIによって情報がレンダリングされる方法を非常に明確に分離できます。
たとえば、メニュー項目を表す単純なクラスを考えてみましょう。
public class MenuItem
{
public string Text { get; set; }
public bool IsChecked { get; set; }
public bool IsEnabled { get; set; }
}
このタイプは、メニュー項目に関するデータのみを公開し、この情報のレンダリング方法に関する情報はありません。実際、クラスの名前(MenuItem)を除けば、これはメニュー項目に固有のものではなく、変更を必要とせずに、チェックされたリストボックスなどの別のUIコントロールで同じデータを使用できます。クラスがWPF固有のユーザーインターフェイス要素を公開している場合、情報は、異なるユーザーインターフェイスコントロールごとに別のタイプで調整する必要があります。