2

MVC C＃アプリ内でデータを検証するための最良の方法を見つけようとしていますが、xValが最適であるように見えました。ただし、データ型の検証で問題が発生しています。

最初は、DTOに対してUpdateModelを実行してから、DTOで検証を実行していました。これは必須フィールドなどに最適ですが、たとえば、文字列（ "asd"）を10進フィールドにマップしようとすると、UpdateModelは例外をスローします。検証するデータが存在する前にUpdateModelを実行する必要があったため、それを回避する方法がわかりませんでした。

私の解決策は、UpdateModelがコピーするフォームごとにDTOを作成し、その検証を実行してから、値を適切なDTOにコピーすることでした。フォームDTOのすべての属性は文字列になるため、UpdateModelが爆破されることはなく、xValを介してデータ検証を実施します。ただし、requiredのようなルールが開始されている間は、DataTypeルールを開始できないようです（この場合はDataType.Currencyを試しています）。

クライアント側の検証を機能させることも試みましたが、データ型のサーバー側の検証を行うためのクリーンな方法があることを望んでいました。

サーバー側でのデータ型の検証に関して、他の人は何をしましたか？

4

2 に答える 2

2

私がやったことは、フォームを表すいくつかのDTOを作成することでした。これらのDTOは、Request.Formを受け取り、フォーム値と同じ名前であることに基づいて、すべてのフォーム値を内部プロパティ（public string email、public string firstnameなど）に自動的にマップします。

それらはすべて文字列プロパティを持ち、xVal属性をそれらに配置します。次に、xValと正規表現を使用して、受信するデータが有効であることを確認します（たとえば、有効な日付、電子メール、番号など）。このように、.Netが日付などに解析しようとするのとは対照的に、例外は常に文字列に含まれるため、例外がスローされることはありません。

これにより、データが常にxValに到達し、必要な検証を実行できるようになります。有効なデータがあることがわかったら、データをDateTimeなどの適切なタイプに変換します。

于 2010-01-07T19:31:20.570 に答える
1

サーバー側で文字列から他のデータ型に解析する必要があるデータを検証するために、ValidationAttributeから派生したカスタムバリデーターを使用しています。例えば：

public class DateAttribute : ValidationAttribute
    {

        public override bool IsValid(object value)
        {
            var date = (string)value;
            DateTime result;
            return DateTime.TryParse(date, out result);
        }
    }

また、カスタムjavascriptコードを記述せずに、このような検証属性をクライアント側とサーバー側の検証属性に変換する方法も見つけました。別の検証属性の基本クラスから派生する必要があります。これについて詳しく知りたい場合は、クライアント側の検証に関する私のブログ記事をご覧ください。

于 2009-09-02T19:05:01.657 に答える