1

私の問題では、いくつかの依存関係に従って、ビュー モデル全体でさまざまなフィールドを検証する必要があります。Silverlight、Prism、MVVM を使用しています。

例として（私の現実世界のシナリオから変更）：

簡単なクラスの例

各船は多くのコンテナを持つことができ、コンテナは多くのアイテムを持つことができます。

各クラスは、プロパティが変更されるたびに継承しNotificationObjectて呼び出します。RaisePropertyChanged

私のビジネス ルールは、プロパティShip.TypeIdが 1の場合、 Item.Colour、Item.Name、およびItem.Sizeが空でないことを確認することです。 Ship.TypeIdが他の値と等しい場合、検証する必要はありません。Itemのプロパティ。

現時点では、OnPropertyChangedイベント内のビュー モデルで検証が実行されています。

私が直面している問題は、Itemクラスに検証を追加すると、オブジェクトがShip.TypeIdを認識しないことです。ItemおよびContainerPropertyChangedによってスローされたイベントをサブスクライブすると、Ship内からプロパティの変更を検出できますが、取得できるのはプロパティ名 (つまり、子クラス、つまり Name) に関連するものだけで、古い値または新しい値は取得できません。

私ができるようにしたいのは、Ship.TypeIdが変更されたことを認識しながら、子アイテムを検証することです。また、どのName、ColorまたはSizeプロパティが変更されたかを認識し、UI の正しいフィールドに対してエラーを発生させることができます。

どうもありがとう、エイドリアン

4

1 に答える 1

2

ご指摘のとおり、Itemは何も知らないのでShip、Shipsを含む検証を行うべきではありません。Itemローカルで検証できるプロパティを追加することは可能かもしれませんが（たとえばCanBeEmpty）、それが理にかなっているかどうかはわかりません。

編集の形式を指定しないため、コメントするのは困難です。船とアイテムの両方を同じ画面でライブ編集できる場合は、アイテムを編集するか、船を編集することで検証が失敗します。この場合、私は通常、[OK]などをクリックしてすべての編集がコミットされるまで検証を延期します。物事を常に有効に保つことを余儀なくされると、複数のものを編集することは本当にイライラします。

アイテムを船から分離して編集することしかできず、アイテム自体の追加のプロパティが意味をなさない場合は、船を認識しているItemEditViewModelでアイテムをラップすることをお勧めします。有効なアイテム編集を作成するには船の知識が必要であるため、これは合理的と思われます。したがって、このような編集画面のViewModelsにも船の知識が必要です。

于 2012-04-18T11:07:11.383 に答える