3

プロパティの値を設定すると、内部値を更新する前または後に検証できます。

以前に検証した場合、新しい値が無効な場合は例外をスローできます。これにより、オブジェクトは常に有効な状態になります。

後で検証する場合は、(つまりIEditableObjectを介して) 元に戻す必要があるため、ユーザーはいつでも編集をキャンセルできます。ここで例外をスローするか、IDataErrorInfoを介してエラーを公開するオプションもあります。

セットの前に検証する場合、IDataErrorInfoは意味がないと思います。また、検証シナリオでは例外をスローすることは保証されないと主張する人もいます。

カスタム オブジェクトが BindingList に含まれ、データ ソースとしてグリッドに設定されているシナリオでは、検証後の検証がうまく機能します。

前の検証はグリッドでも問題なく動作しますが、プロパティ値の設定が失敗したことをデータ グリッドに通知するために、例外をスローする必要があります (多くの追加コードは必要ありません)。

IEditableObjectIDataErrorInfoINotifyPropertyChangedなどを実装するドメイン オブジェクトにも満足できません。ドメイン オブジェクトが余分な懸念事項で雑然としたままになります。しかし、データバインディングでniceを配置したい場合はやむを得ないようです。ラッパー、おそらく DTO を作成することもできますが、これらのデータバインディング ビットをサポートするためだけに、ほとんどダミーの追加コードを書かなければならないことにあまり夢中ではありません。

オブジェクトをどのように検証しますか (できればデータバインディングと UI のコンテキストで)。

4

1 に答える 1

1

Business Objects, Validation And Exceptionsに対する私の回答を参照してください:検証に関するPaul Stovellのアイデア (この記事にまとめられています) は信じられないほど強力だと思います。

IDataErrorInfoドメイン エンティティ (および場合によってはIEditableObjectと) に実装するINotifyPropertyChangedことで、多くのコードを使用せずに、多くの .NET プレゼンテーション テクノロジ (Windows フォーム、WPF、ASP .NET...) でデータ バインドできるようになります。または、スクリプトまたはバッチ (つまり、非 UI プロセス) でそれらを使用することもできますが、ビジネス ルールに対してそれらを検証する可能性があります: スムーズに (現在のエンティティの状態をクエリする) または困難な方法 (無効な場合は保存時に例外をスローする) のいずれかです。

重要なことは、このパターンでは、ドメイン エンティティが独自の検証を担当することです (これは良いことであり、余分な懸念のようには見えません)。それらが無効な状態にある場合、保存時に意味のある例外をスローすることにより、それを強制します。また、最初に質問したい場合は、それらが有効かどうかを知らせることで、コード (UI かどうかに関係なく) を適切に操作できます。

私のソフトウェア ファクトリ プロジェクト (まだ初期段階) であるSalamancaでは、ドメイン モデルを超えてこれらの原則を適用しています。

于 2009-08-06T13:14:48.397 に答える