1

私が取り組んでいる WPF プロジェクトでは、ビュー モデルのプロパティの属性を介してデータ検証を実装することを検討しています。

例：

[RegexConstraint("^[A-Z][a-zA-Z]+$")]
public string Name 
{
    set
    {
         _name = value;
         OnPropertyChanged("Name")
    }
}

すべてのビュー モデルは、IDataErrorInfo を実装する共通の ViewModelBase クラスから継承します。インデクサー:

string IDataErrorInfo.this[string columnName]

名前でプロパティを取得します (リフレクションを使用)。

var properties = GetType().GetProperties().Where(p=> p.Name == "someName")

すべての制約属性を検索します...

private static ICollection<IValidator> GetValidations(PropertyInfo property)
{
 return (ValidationAttribute[])property.GetCustomAttributes(typeof(ValidationAttribute), true))
            .Select(va => new AttributeValidator(va)).Cast<IValidator>().ToList();
}

...そして検証を実行します

うまくいくようですが、私の質問は、同様の手法を使用した経験がある人はいますか? それは悪い考えですか？

これにより、コードがよりクリーンで簡潔に見えるようになり、すべてのビュー モデル クラスで IDataErrorInfo を実装する必要がなくなりますが、一方で、検証ロジックがプロパティに依存している場合に、きれいなユーザー メッセージを作成する方法という新しい問題が発生します。ハードコーディングされたメッセージを使用するのではなく、名前/属性名を使用します-私が見つけることができたすべての IDataErrorInfo の例のように。

要約すると、私の質問は、この道を進み続ける必要があるか、それとも別の検証スキームを使用する必要があるかということです。

4

2 に答える 2

1

私はいくつかの異なるプロジェクトでこのような手法を実行しましたが、ほとんどの DataAnnotation 属性でエラー メッセージを制御して、より使いやすくすることができます。最近 2 つの大きな WPF プロジェクトでこれを行い、現在 3 番目のプロジェクトでも同じことを行っているため、これは完全に実行可能なソリューションです。ここで注意が必要です... 多くの複雑なビジネス ルールを処理するために、多くのカスタム DataAnnotation クラスを作成する必要があることがわかりました。これは、データに関するビジネス ルールの複雑さに依存します。主にすぐに使用できる DataAnnotations を使用してアプリで検証をサポートできる場合は、この同じ課題に直面することはありません。エラー メッセージに関する限り、次のように DataAnnotation 属性に名前付きプロパティを設定できます。

    [Required(ErrorMessage = "Title is required.")]

したがって、「FirstName」のような名前のプロパティのメッセージをきれいにして、「First Name is required...」としてメッセージに表示できます。

また、基本クラスのすべてを IDataErrorInfo に接続する作業を行っている限り、WPF アプリでゴールデンになります。それはあなたのコードをよりきれいにし、あなたが書かなければならないことを最小限に抑えます（必要な場合はカスタム検証属性を除く）。

于 2012-08-03T03:25:52.647 に答える
1

私には有効なアプローチのように思えますがDisplayName、などを使用して素敵なメッセージを取得できます。完全なメッセージの場合、リソース ファイルで検索されるキーを持つ属性を持つことができます。

于 2012-08-03T02:28:45.603 に答える