クライアント側とサーバー側の検証が行われるとき、より良いUXがサーバー検証のみを行うようになりますか？
Fluent Validationを使用して、現在取り組んでいるMVC4プロジェクトに問題が見つかりました。一部の検証はjQueryクライアント側の検証に委任されていますが、ドロップダウンのNotNullルールやフィールド値に基づくいくつかの条件付き検証など、サーバー上で実行する必要があります。
その結果、ユーザーはいくつかのドロップダウンといくつかのテキストボックスを空白のままにするか、ドロップダウンで特定の値を選択します。次に、[送信]を押して、クライアント側の検証のメッセージを取得し、修正します。次に、[送信]を再度クリックし、サーバー側の検証に関する他のメッセージを再度取得します。これらのメッセージを修正して、[送信]を再度クリックする必要があります。
サーバー側の検証が不要なページの約5％を持っているので、クライアント側をオフにすると、はるかに優れたUXになります。ユーザーはすべての検証メッセージを一度に取得し、すべての修正を一度に試行して再送信できます。
セキュリティにはルールサーバー側の検証を使用し、ユーザビリティにはクライアント側の検証を使用します。
クライアントを信頼することはできませんが、入力をすばやく（ネットワークなしで）検証する標準クライアントを作成できるので、ユーザーは入力中でも時々応答を受け取ることができます。
これにより、クライアントがサーバーに送信する誤った要求myも最小限に抑えられます。
-編集-
私が言いたいのは：
クライアント側の検証に時間を費やすことなく検証を実行し、decent結果を取得できます。
プロ：
- one検証を実装するだけです。
- 2レベルのエラーメッセージはありません。サーバーからのoneだけです。
コントラ：
- すべての誤った入力の場合、サーバーへの1つの誤ったリクエストを受け取ります実装したクライアントのみが使用されます。
- ユーザーは何が問題なのかを知るためにサーバーの応答を待つ必要があります。
おそらく必要なのは、同じ構成をとるtwoバリデーターを実装しているため、クライアントの構成およびサーバー。これにより、2つのレベルエラーおよびの問題が解消され、クライアント側の検証の利点が得られます。
これは迷惑です。ユーザーはフォームに記入して送信し、「3つの間違い」を取り戻します。彼はこれら3つの間違いを修正し、送信し、その間に変更していないフィールドで「2つの新しい間違い」を取り戻します。彼の反応：
「そもそもなぜ2つの間違いについて教えてくれなかったのですか」
そして彼は正しい。
クライアントサイドの検証は、より迅速なフィードバックを提供することでユーザーを支援することを目的としています。ユーザーが[送信]をクリックするのを待つと、そのEdgeのほとんどが失われます。サーバーへの往復時間のみが節約されます。これは、最近のほとんどの場合最小限です。特に、2つの送信のコストが発生する場合、クライアント側の検証はユーザーを助けているのではなく、ユーザーを困らせています。
2つの修正：
1/clientsideソリューションを用意するimmediate：ユーザーが間違ったメールアドレスを入力するとすぐに（フィールドがフォーカスから外れる）、手掛かりを与えます（ボックスを表示し、色を付けます）赤のフィールド）は、電子メールアドレスの形式が正しくなく、サーバーで受け入れられないことを示します。
2 /クライアントサイドのソリューションを即時に実行できない場合は、無効にするにします。すべてのエラーをキャッチし、すべてを一度に表示するサーバー側検証を1つ用意します（最初のエラーで停止せず、ユーザーに修正してもらい、エラーごとに繰り返します）。
完璧な世界では、クライアント側の検証はユーザーが犯す可能性のあるあらゆる間違いをキャッチしますが、これが不可能であることはよくあります。ユーザーもこれに慣れました。クライアント側の検証がサーバー側の検証がキャッチするミスのサブセットのみをキャッチする場合、誰も怒りません。
これが私がよくクライアントサイドで80％の最も一般的なエラーのみをコード化するであり、エッジケースをサーバーサイドに任せる理由です。最も一般的なエラーがサーバーサイドでのみ確認できる場合（たとえば、「ユーザー名はすでに使用されています」）、小さなAJAXリクエストで不思議に思うことがあります：ユーザーがフォームに入力し続けている間、彼は気づくでしょう彼のユーザー名はすでに使用されており、別の名前に変更できます。
私はオンザフライサーバー検証の大ファンです。
大量のデータ（大きなファイルのアップロードなど）を扱っていない場合、検証のためにフォームの一部をサーバーに自動的にAJAX送信することはそれほど難しくありません。これは、ユーザーがメールアドレスやパスワードなどを入力するだけでなく、一意のユーザー名を選択する必要があるサインアップフォームでよく見られます。
クライアント+サーバー検証モデルを使用
- ユーザー名「I-Love-Kittenz」を入力します
- クライアント側のエラー「特殊文字は使用できません」
- ユーザー名を「ILoveKittenz」に変更します
- クライアント側はエラーを出しません
- ユーザーがフォームを送信する
- サーバー側のエラー「そのユーザー名はすでに使用されています！」
- ユーザーはイライラして別のユーザー名を試します
オンザフライサーバー検証モデルの使用
- ユーザー名「I-Love-Kittenz」を入力します
- クライアントがサーバーをポーリングし、「特殊文字は使用できません」というエラーが発生する
- ユーザー名を「ILoveKittenz」に変更します
- クライアントがサーバーをポーリングし、「そのユーザー名はすでに使用されています！」というエラーが発生する
- ユーザー名を「ILoveK1ttenz」に変更します
- クライアントがサーバーをポーリングしてOKになる
- ユーザーが送信し、満足しています！
クライアント側の検証は高速であるため、通常は望ましい方法です。検証は、フォームが送信される前に行われます。ユーザーは、サーバーが応答するまで数秒待つ必要はありません。
JavaScriptを持たないユーザーや悪意のあるユーザーがJavascriptを使わずに不正なデータを送信する可能性があるため、通常はサーバー側の検証が必要です。
ベストプラクティスは通常、両方にsame検証を実行して、ユーザーにとって高速になるようにすることですが、サーバーは不正なデータから保護されます。
ユーザーは、どこでどのように検証されたかを知る必要はありません。
両方の検証を実行し、両方の検証のエラーを同じダイアログに表示します。そうすることで、検証、修正、および検証と修正を再度行ったという残念な経験が取り除かれます。ユーザーはすぐに何が問題かを理解し、最初のエラープロンプトの後にすべての問題を修正することを知っています。
クライアント側の検証なしで実行できますが、サーバー側の検証なしでは実行できません。
イフもノーもない。
サイトをハッキングしたい場合は、クライアント側の検証を利用してください。
クライアント側の検証を使用して、サーバー側の検証で検出されるエラーの量を最小限に抑える必要があります。サーバー側の検証の代わりに使用しないでください。
ただし、サーバー側の検証に依存している場合、フォームがリモートで複雑であると、実際の混乱に終わる可能性があります。したがって、最良の結果が必要な場合は両方を使用するか、プログラミングが容易でビジネスルールの単一点が必要な場合にのみサーバー側を使用してください。ただし、クライアント側のみを使用しないでください。ずっと。
あなたの問題は、クライアント側とサーバー側の両方の検証があるということではありません。あなたの問題は、クライアント側がサーバーが行わないことを検証していることです。それは完全に無意味です。
クライアント側の検証では、サーバーよりも多くの検証を行うべきではありません。これは、ユーザーのコンピュータで既に判断できる何かを発見するためにユーザー時間/サーバーリソースを無駄にしないこと、つまり失敗することを目的としています。サーバーは非常に頻繁に、ユーザーに公開したくないビジネスロジックを使用して、クライアントが決してすべきでないことを検証します。
つまり、はい、サーバーでよりも厳しいルールを設定しているクライアントがある場合は、オフにします。 1つのサイズでクライアント側のすべてのソリューションに適合する場合は、各シナリオに合わせてカスタマイズできるソリューションを検討することをお勧めします。
提案どおりにすべてのページでクライアント側の検証をオフにすると、本当にすべての検証メッセージが一度に表示されますか？実際には、クライアントサイドとサーバーサイドの検証手法に関係なく、ほとんどの重要なフォームには2段階の検証が必要です。
- 入力の検証-例必須フィールド
- ビジネスルールの検証-例選択の組み合わせは、より大きなビジネスコンテキストで有効です。
そうは言っても、私は何年も前にクライアント側の検証をあきらめました。私は短所が常に長所を上回っていることを発見しました。
短所：
- プログラミング作業の重複（検証もサーバーで実行する必要があります）、またはFluentValidationなどのライブラリに依存して、必要な方法で機能します。
- テスト作業の重複
- 一貫性のないユーザーエクスペリエンス。つまり、クライアント側の検証は通常、ほぼ瞬時に、ほとんどぎくしゃくしています。サービス側の検証には遅延がありますが。
- ...
長所：
- ユーザーにとってより速い
- サーバーの負荷が少ない
ただし、サーバー側を100％実行する場合は、ページ全体のPOSTからAjax POSTに移行する必要があります（まだ移行していない場合）。これにより、リクエスト/レスポンス時間が大幅に短縮されます（検証が失敗した場合は、ページ全体を再構築する必要がなく、たとえば検証結果のリストのみが返されます）。言うより簡単ですが、このパラダイムをサポートするすぐに使えるライブラリ/フレームワークはあまりありませんが、ここで説明する検証を含め、多くの点で努力する価値があります。