4

ご清聴ありがとうございました。

プロパティのセッターに検証を実装したい。ここにあなたの専門家の助けが必要な問題があります。

値を設定する前に、どのように検証を行うかについての考えがあります。ただし、渡された値が正しくない場合はどうすればよいかわかりません。適切なメッセージを（Webフォームのラベルで）ユーザーに返したいので、設定しないだけでは受け入れられない解決策です。私のサンプルコードは次のとおりです。

private  int id;
public int Id
{
    get
    { return id; }

    set
    {
        bool result = IsNumber(value);
        if (result==false)
        {
            // What to do if passed data is not valid ? how to give a appropriate message to user that what is wrong ?
        }

        id = value;
    }
}

returnを使用することを考えましたが、許可されていません。

通常、カスタムエラーのスローを回避するため、エラーのスローは適切ではないように見えます。

案内して助けてください。

期待してくれてありがとう

ハンシ

4

4 に答える 4

1

次の理由により、別の例に変更した方がよいと思います。

public int Id
{
  get { ... }
  set 
  { 
      if (!IsNumer(value)) // changes to if (value>5)
      {
            //the code here will never be executed
           id = value;
      }
  }
}
于 2010-06-08T07:45:53.607 に答える
1

プロパティセッターから適切な例外をスローすることを検討できます。そうすれば、特にプロパティの設定に関するビジネス ルールがあると仮定すると、何がうまくいかなかったのかが呼び出し元に明らかになります。もちろん、呼び出し元が検証を行うことを期待していますが、それでも問題がある場合は、例外をスローすることはそれほど悪いことではないようです。

「プロパティセッターから例外をスローすることは有効であり、受け入れられます。」 プロパティの設計ガイドライン

ベスト プラクティス: プロパティからの例外のスロー

プロパティ セッターからスローする例外は?

于 2010-06-08T09:39:39.670 に答える
0

  1. チェックが数値 (型) のみに関するものである場合、プロパティは型の安全性を非常にうまく処理できます。例えば。ユーザーは、int を受け入れるプロパティに文字列を割り当てることができません。

  2. プロパティに特定の計算が含まれる場合は、代わりにメソッドの使用を検討することをお勧めします。その場合、代わりにテキストを取得するオプションがあります。

  3. もう 1 つのオプションは、これらすべての検証チェックをインスタンス コレクション (同じオブジェクト内) に格納することです。お気に入り。

    プライベート リスト _faileValdations;

//その他のコード

    set
    {
    if (!IsNumber(value))
    {
    _faileValdations.Add("Invalid value for xxx. Expected... got..");
    }
    else{
        id = value;
    }
    }

その後、GUI は最後に FailedValidations コレクションを読み取り、フォーマットされた方法でラベルに表示できます。

編集：以下のもう1つのオプション。

  1. すみません、前にこれについて言及するのを忘れていました。

イベント駆動型アプローチも使用できます。オブジェクトは「ValidationFailed」などのイベントを公開でき、すべての GUI オブジェクトはこのイベントをサブスクライブできます。セッターで検証が失敗した場合、オブジェクトはこのイベントをトリガーします。

    set {
    if (!IsNumber(value))
    {
    RaiseValidationFailed("some message");
    }
    else{
        id = value;
    }
    }

「RaiseValidationFailed」はメッセージを収集し、それをいくつかのイベント引数にラップして、メッセージで「ValidationFailed」イベントをトリガーできます。その後、GUI はこれに反応できます。{明確でない場合は、完全なコードを提供できます}

于 2010-06-08T07:44:20.150 に答える
0

検証へのアプローチを再考する必要があると私は主張します。あなたが提案しているアプローチは、プロパティが変更されるたびにメッセージが生成されることを意味します。

これらのメッセージはどのように収集、保存、提示されるのでしょうか? 特に、Web サイトでクラスを使用することにした場合はどうでしょうか?

それ以外のときにクラスを検証したい場合はどうしますか?

クライアント側の検証で同じルールを使用したい場合はどうしますか?

無効な値をできるだけ早くキャッ​​チする利点は理解できますが、Validate() メソッドなどの 1 回の呼び出しでクラス全体を検証する方がはるかに簡単です。このようにして、検証ロジックがいつ実行されるかを完全に制御できます。

プロパティ検証への 2 つの主要なアプローチを読むことをお勧めします。

データ注釈

>NET 3.0 以降の流暢な検証

.NET 2.0 の流暢な検証

Data Annotations と FluentValidation はどちらも使いやすく、Web フォームと win フォームで十分にテストされたクライアント側の検証を生成できます。

データ注釈では、属性を使用して検証がプロパティに追加されます。データ クラスをクリーンなデータ転送オブジェクトとして維持したい場合、Fluent 検証では、Validator クラスで読みやすいルールを作成します。

于 2010-06-08T08:14:01.863 に答える