2

ビジネス オブジェクトで検証を使用する方法を理解しようとしています。

これまで、1 つのエラーのみをチェックするCustomValidatorの例しか見たことがありません。3 つ以上のエラーをチェックする必要がある DateTime 入力を持つ 2 つのフィールドがあります。私は通常、クライアントでチェックし、次にサーバーでチェックし、最後にデータベースレベルでチェックする必要があると思います。

  • フィールドでエラーが発生した場合、フィールドを離れることはできません。
  • クライアント検証では、これは単なるユーザー エラーであるため、例外を引き起こすエラーではありません。ただし、何か問題が発生し、ユーザーがクライアント検証をバイパスした場合、サーバー検証は例外を開始する必要があります。
  • 最後に、バッチ更新などの他の作業がある場合は、データベース検証コードを使用する必要があります。基本的なことを見逃している場合は、修正してください。
  1. `dateFrom` は空ではありません。(ただし、「dateTo」は空にすることができます)
  2. `dateFrom` は `dateTo` より前です
  3. `dateFrom` と `dateTo` は定数 `MinDate` と `MaxDate` 内にあります

では、検証はクライアント、サーバー、データベースのように見えるべきですか?

感想:

検証ロジックを 3 つの異なる場所に分ける必要があります。UI、コード、DataObject(データベース)? まったく同じコードの場合は? 冗長に見えますか？

3 つのチェックすべてに同じ検証方法を使用できますか? または、3 つのコード チャンクとそれぞれに 3 つのメソッドを実装する必要がありますか?

4

2 に答える 2

2

コードの重複とそれに起因するエラーを減らすには、すべての検証コードを単一のレイヤー (できればビジネス レイヤー) に配置する必要があります。これは、オブジェクトを評価して有効かどうかを判断するのに最適な位置にあるためです。

ただし、これは理論上の理想ですが、実際の状況では実用的ではないことがよくあります。ASP.NET などのクライアント サーバー環境では、サーバーへのラウンド トリップを減らすために、クライアント側でできるだけ多くの検証を複製する必要があります。また、ビジネス オブジェクトを介さずにテーブルにアクセスする他のビジネス プロシージャ (バッチ アップロードなど) がある場合は、データベースにも検証を実装して、ガベージ データが作成されないようにする必要があります。

あなたの例のような検証では、ビジネス オブジェクトに 3 つの検証メソッドと 3 つの CustomValidators を作成します。各バリデータは、サーバー側のビジネス オブジェクトで対応するメソッドを呼び出します。また、クライアント側で実行するように JavaScript をコーディングします。そのため、サーバー側のコードは、JavaScript が有効でないブラウザーや、悪意を持って作成された HTTP 要求をキャッチするためだけに存在します。

JavaScript で行うのが難しい (つまり、ビジネス オブジェクトが必要な) 検証については、CustomValidator を気にしません。代わりに、これらの検証は、ユーザーが送信ボタンを押すまで待機します。送信ボタンが押された時点で、ビジネス オブジェクトを使用してそれ自体を検証し、エラーを返すことができます。

于 2010-02-22T14:22:36.157 に答える
1

通常、通常、ビジネス層での検証は適切です。往復を減らすのに役立つので、JS 検証も優れています。CustomValidator には、クライアントで検証するメソッドの名前を取得し、検証を実行するメソッドの名前に設定する cleintvalidationfunction プロパティがあります (これについては MSDN ドキュメントを確認してください。申し訳ありませんが、手元にリンクがありません。 、しかしMSDNには明確な例があります)。

また、サーバーの場合、servervalidate イベントを発生させてコードからフォームを検証することもでき、ここでも DB チェックを実行できます。

DataObject(Database) で何をチェックしているのかわかりませんか?

于 2010-02-22T14:03:38.740 に答える