別のチーム (同じ会社) によって開発されたユーザー コントロールを使用しようとしています。開発中のアプリでは、XAML ですべてのデータ バインディングを記述しようとしています。
サードパーティのユーザー コントロールを使用する場合、コードのフックを備えた基本的な ViewModel を提供することを期待する必要がありますか?それとも、ユーザー コントロールを選択した ViewModel にバインドするコードを記述することを期待する必要がありますか?
乾杯
AWC
別のチーム (同じ会社) によって開発されたユーザー コントロールを使用しようとしています。開発中のアプリでは、XAML ですべてのデータ バインディングを記述しようとしています。
サードパーティのユーザー コントロールを使用する場合、コードのフックを備えた基本的な ViewModel を提供することを期待する必要がありますか?それとも、ユーザー コントロールを選択した ViewModel にバインドするコードを記述することを期待する必要がありますか?
乾杯
AWC
これは、UserControl のスコープによって異なります。それがアプリケーションに固有であり、他の場所で役立つ可能性が低い場合は、はい、おそらくパブリック ViewModel を提供する必要があります。
ただし、パブリック ViewModel は、コントロールが再利用可能であると予想される場合、あまり役に立たない可能性があります。コントロールは ViewModel を内部的に使用する場合がありますが、これはプライベートに保つ必要があります。次に、ホスト アプリケーションは、他の WPF コントロールと同様の方法でコントロールを使用し、独自のビュー モデルを作成してコントロールをアプリケーションに関連付けます。
本質的に、ViewModel は通常、アプリケーションに固有のものであり、そのアプリケーションのニーズに合わせて特別に調整されています。一方、汎用コントロールは、任意のアプリケーションで使用できるようにするプロパティとイベントを公開します。
コントローラ クラスを自分で作成します。再利用可能なコントロールは、特別に作成されていない限り、操作対象のデータの種類を認識しない必要があります。しかし、それはあまり再利用可能ではありません:)
コントロールは、自己完結型ユニットとして提供されます。フックが公開されている独自のビューモデルが内部にある場合、それはすべて素晴らしいことですが、直接操作できないため、問題はありません。
本当に必要な場合は、提供されたコントロール用に独自のビューモデルを作成する必要があります。これにより、コントローラー (コード) から UI (提供されたコントロール) が抽象化されます。これは、パターンの目的の 1 つです。関心を分離することで、残りの部分への影響を最小限に抑えながら任意の部分を交換できます。
ただし、すべてのコントロールが独自のビューモデルを必要とするわけではありません。代わりに、提供されたコントロールをより大きなユーザー コントロールの一部として使用し、そのより大きなコントロールのビューモデルを記述します。