1

誰かがこれらの用語を明確にしてください。
私はそれらが非常に曖昧または文脈依存であると思います。

たとえば、アイテムリストを含むVMがあります。選択は、ボタンのアクセス可能性(つまり、コマンドを実行できる)だけでなく、VMの動作にも影響します。1つまたは複数のアイテムを同時に編集する必要があることが重要です。

2番目の例は、新しいアイテムを作成するプロセスです。
ユーザーがデータを提供した後、アイテムをアイテムコレクションに追加してリストに挿入し、選択してフォーカスを絞ります。次に、アイテムのVMのプロパティを導入してこれを行いIsSelectedます。IsFocused実際の仕事は、バインディング、アタッチされたプロパティ、および動作を介してビューによって実行されます。

私たちのチームの一部のメンバーは、このような種類のプロパティ(、、など)をVMに追加するIsVisibleIsSelectedIsFocusedUIロジックがVMにもたらされると主張していますが、UIとプレゼンテーションロジックが混在しているため、これは適切な方法ではありません。

私にとって、次のパターンは重要ですが、繰り返さないことがより重要です。DataContextを具体的なVMの型にキャストしたり、VMのメソッドを呼び出したりせずに、バインディングとコードビハインドの数行を使用することをお勧めします。

それにもかかわらず、私はHolyWarsが好きではなく、これら2つの用語の誤解と、一方を他方から分離する基準のために、私が間違っている可能性があることを認めます。

4

1 に答える 1

3

プレゼンテーション ロジックを VM に配置し、IsEnabled などのプロパティを VM に配置することが重要だと思います。これにより、テストが可能になります。これにより、ビューの複雑さも軽減され、単体テストできないコードの量が減ります。

さらに、VM でのプレゼンテーション ロジックがベスト プラクティスではない理由について、同僚が持っている可能性のある参考文献に興味があります。IMHO UI はプレゼンテーション層の一部であり、VM の目的はビューをモデル化することです。したがって、ここにプレゼンテーション ロジックを配置するのは自然なことのように思えます。

追加編集:

MVVM パターンの実装から

ビューの責任は、ユーザーが画面に表示するものの構造と外観を定義することです。ビューのコード ビハインドには、InitializeComponent メソッドを呼び出すコンストラクターのみが含まれていることが理想的です。場合によっては、コード ビハインドに、複雑なアニメーションなど、Extensible Application Markup Language (XAML) で表現するのが困難または非効率的な視覚的動作を実装する UI ロジック コードが含まれる場合があります。ビューの一部。単体テストに必要なロジック コードをビューに配置しないでください。通常、ビューのコード ビハインドのロジック コードは、UI 自動化テスト アプローチによってテストされます。

于 2013-02-01T09:23:17.897 に答える