2011-12-08 9 views
1

私が読んできたことの多くから、データの注釈を使用して検証することが常に望ましいと思われます。 JavaScriptの開発者であるため、私は自動生成されたJavaScriptについていつも気になるわけではありません。DataAnnotationsの自動生成されたjQueryコードがAntiPatternですか?

地域社会の取り組みをご希望ですか?まず、説明しましょう。私が持っている場合は

はただの平らな、単純な形式は、このようなクラスにそのマップをテキストボックス:

public class Person 
    { 
    [Required] 
    public string FirstName { get; set; } 

    [Required] 
    public string LastName { get; set; } 

    [Required] 
    public DateTime DateOfBirth { get; set; } 

    [Required] 
    public string State { get; set; } 
    } 

ビューは非常に簡単(textboxfor年代やeditforのの束)にすることができ、我々は強く型付けされたことができますPersonオブジェクトに対してクライアント側の検証が有効になっている場合、jQueryコードは自動的に生成され、クライアント側の検証を行うためにコードを書く必要はありません。 「うまくいく」というだけでなく、このようなフォームフィールドを扱っているのであれば、このようにするのが理にかなっています。

私は40種類以上のフォームフィールド(ドロップダウン、マルチセレクトボックス、チェックボックスなど)を持つ巨大なフォーム(IRSやイントラネットサイトを考えてみましょう)を扱っていると、非常に面倒です。

  • フォームは、他の フォームの可視性をトリガーするフォームフィールドを有することができること:また、あなたが書くJSがあなたのC#にあまり頼ることになる独自のバリデータを書き込むことにつながる、これらのシナリオに遭遇する可能性がありフィールド。
  • あなたは[必須]として設定されているdateOfBirthのフィールドを持っている場合は、 がクリックされたとき、それはあなたが 新しいバリデータを作成するために持っているデザイナーと並行して作業することができ
  • それが不要になるというボタンがあるかもしれませんC#コード(またはデータ 注釈など)に触れたくありません
  • ページの他の検証フレームワークで作業することができます。これらすべての可能性を秘めた

、それはどんな自動を使用しないように理にかなっている(データ注釈から)JavaScriptを生成し、ClientSideValidationをオフにすると、任意のC#の依存せずにjQueryの検証プラグインを使用して、ちょうどHTMLを確認する以外に要素が存在し、選択可能である。

あなたは同意しますか?私は何が欠けていますか?

答えて

2

あなたが欠けているのは、「自動生成」のJavaScriptがないことです。クライアント側の検証では、jqueryの検証とhtmlデータの属性が使用され、javascriptは生成されません。アダプタークラスを使用して属性を解析し、jqvにフィードします。アダプターは自動生成されません。

データの注釈はあまり柔軟ではありませんが、jqueryやコードの自動生成とは関係ありません。データアノテーションは静的でコンパイル時に作成されるためです。

これは問題の一部に過ぎません。クライアント側の検証を無効にしたとしても、手動で行うクライアント側の検証に関係なく、サーバー側の検証を処理する必要があります。クライアントから送信されたデータを信頼することは決して望まないので、クライアント側の検証のみを行うことはできません。サーバー側で動作するソリューションが必要であり、うまくいけばクライアント側でも動作します

fluent validationのようなものを使用すると、実行時の検証をより詳細に制御できます。可能であれば、クライアント上のjqueryの検証と結びついています。

+0

それを見ていただきありがとうございます。 – SaltProgrammer

関連する問題