3

これは、XML を検証する最善の方法についてアドバイスを求める技術的な問題ではなく、むしろ質問です。

着信 Xml 要求を受け入れる C# で記述された Web サービスがあります。

現在、受信 Xml を XSD スキーマに対して検証しています。これは問題なく動作し、エラーをキャプチャして適切なメッセージで応答できます。

さらに、すべてのプロパティを検証するために、オブジェクトを渡すことができる次の関数があります。

    private List<ValidationResult> Validate(object oObject)
    {
        var results = new List<ValidationResult>();
        var context = new ValidationContext(oObject, serviceProvider: null, items: null);
        Validator.TryValidateObject(oObject, context, results, false);
        return results;
    }

そして、次のように定義された要素を検証します。

    [Required]
    [StringLength(175)]
    public string Name{ get; set; }

この関数は、見つかったエラーの文字列リストを返します。

XSD スキーマとクラス プロパティが検証要件に関して同期している場合、私のコードは関数で結果のリストを返さないように見えます。

private List<ValidationResult> Validate(object oObject)

XSD スキーマにより、コードがその時点に到達することが妨げられるためです。

これは XML 検証を実行する通常の方法ですか?

4

1 に答える 1

1

はい、要求に対して両方のタイプの検証 (XSD とアプリケーション固有) を実行するのが普通です。

XSD は、要求の期待値の共有可能な (および実行可能な) 仕様です。XSD の共有仕様に関して、要求の問題をクライアントに自動的に通知できるのは利点です。

ただし、一部のチェックは XSD で表現できません (便利な場合もあれば、まったく表現できない場合もあります)。たとえば、XSD 1.0 については、XSD 1.1 のすべての動機付けの例を参照してくださいxs:assertion。XSD 1.1 の場合でも、XSD に関して帯域外のリクエストのチェックを実装することが必要または好ましい場合があります。たとえば、サービスが特定の方法で実装されている間は、実装レベルのチェックが必要になる場合がありますが、サービス インターフェースにそのチェックを永続的に負担させる必要はありません。または、リクエストの一部の側面をチェックするために、複雑で現存する手続き型コードが利用される可能性があり、XSD で宣言的に表現するよりも不可能または扱いにくい場合があります。

できるだけ多くの検証制約を XSD に配置しますが、本来はそこに収まらないチェックも保持します。2 番目のレベルの検証は、価値があり実用的です。

于 2013-11-09T00:36:31.027 に答える