10

私はMVVMのパターンが好きで、使い始めるとハマってしまいます。

完璧な世界では、View のコード ビハインドはほとんど空 (おそらくコンストラクター内のコード) であり、View のあらゆる側面が ViewModel から操作されていることを私は知っています。

ただし、ViewModel で新しいフィールド、プロパティ、コマンドを作成すると、イベント ハンドラーで同じことを実装するよりも多くのコードが作成される場合があります。

現時点では、次のルールに固執しています。

イベント ハンドラー コードがビューのごく一部を操作する場合 (たとえば、ボタン クリック イベント ハンドラーが同じビューにある特定の TextBlock のフォントを大きくする場合)、イベント ハンドラー内にロジックを実装してもかまいません。ただし、View がビジネス ロジックを操作したり、View の外部にあるリソースにアクセスしたりする必要がある場合は、これらの責任を ViewModel に割り当てます。

私のアプローチについてどう思いますか?

イベント ハンドラーと ViewModel を使用するときに避けるべきことは何ですか?

MVVM パターンを使用する際に推奨できるベスト プラクティスは何ですか?

4

2 に答える 2

15

あなたの経験則は悪くないと思います。

私の見解では、中心的な関心事は「コード ビュー固有か、それともビジネス ロジックに対応しているか」です。

コードが厳密にビューを変更し、いかなる種類のビジネス ロジックも実行しない場合は、ビューにコードを含めることは問題ありません。フォントサイズを変更する例は、ビューで完全に問題のないコードの代表的な例です (ViewModel のノイズが増加し、理解と維持が難しくなります)。本質的に、トリガーを使用する場合は、すでにいくつかのことを行っているため、それほど奇妙ではありません。

ただし、単体テストを使用する場合、そのビュー ロジックをテストするのは非常に困難になることに注意してください。テストが必要な場合は、ビューモデルに配置する方がよい場合があります。

于 2009-04-01T11:53:43.177 に答える
2

前回のコメントにも追記できると思いますが、

イベント ハンドラーを使用する代わりに、非常に控えめな経験から、コマンド自体のステータスをチェックする機能を備えたさまざまなコントロールからのイベント/アクションに応答する独立したメカニズムを提供するという意味で、コマンドははるかに柔軟性を与えてくれます。

于 2010-09-22T10:45:05.583 に答える