2

ウィンドウのマスター セクションには、DataGrid が含まれています。詳細セクションには、マスターの DataGrid で現在選択されているレコードを編集できるフォームが表示されます。グリッドの SelectedItem はマスター VM にバインドされます。そのプロパティが変更されると、マスター VM は新しい EditViewModel を作成し、プロパティを介して公開します。ビューの詳細セクションは、このプロパティをその DataContext として使用します。

キャンセルなどのコマンドを実装する場合、それらをマスター ビュー モデルと詳細ビュー モデルのどちらに配置しますか?

詳細ビュー モデルは、ユーザーのレコードとのやり取りを担当します。この責任には削除が含まれると主張することができます。一方、マスター ビューはコレクションとのユーザー インタラクションを担当し、削除はコレクションを変更するため、削除機能をコレクションに配置する必要があると主張することもできます。

ありがとう、
ベン

編集：明確化-「コマンドを実装する」とは、サービスレイヤーに要求されたアクションを実行するように要求するコードを実装することを意味します。

4

3 に答える 3

5

あなたの 2 番目の主張は、最初の主張よりもはるかに強力だと思います。

あくまで個人的な意見ですが、削除は個人の記録ではなく、コレクションの問題のように思えます。

于 2010-07-13T22:19:34.007 に答える
2

私は Ian の答えに同意しますが、個人的には UI ロジックとモデル ロジックの区別が重要であると考えていることを付け加えておきます。

したがって、削除がこの時点で主に UI リストからのものである場合、削除をコレクション VM に配置することは非常に理にかなっています。

モデルの操作 (たとえば、データベースからのレコードの削除) について話し始めるとすぐに、レコードはおそらくこのロジックの正しい場所です。

さらに、モデルに影響を与えるこの種のロジックは、ドメイン モデルに移動し、ビュー モデルから移動する必要があります。VM は可能な限り UI ロジックのみを担当し、ドメイン モデルはリッチな表現に成長します。ビジネスロジックの。

于 2010-07-14T02:33:26.930 に答える
0

各レコードはそれ自体を知っているだけです。それがコレクションの一部であり、それ自体がエンティティであることを認識すべきではありません。マスターVMにはレコードのコレクションがあるため、変更を担当する必要があります。

また、UIロジックとビジネスロジックを分離することについてDavidに同意します。ビジネスモデルが変更されると、ビューモデルコードが破損し、さらにDRYの原則が維持されるため、スパゲッティコードには近づかないでください。

于 2010-07-14T12:48:06.920 に答える