私は、多数のページで構成される WebForms アプリケーションに取り組んでおり、各ページにはユーザーが入力するフォームが含まれています。各フォームはエンティティの一部に対応します。つまり、1 つのページ/フォームからのデータがエンティティのフィールドまたはその子エンティティのフィールドの一部に入力されます。
例として、個人の名前と出生データが最初のページに記入され、2 ページ目に健康状態が、3 ページ目に家族情報が記入されます。もちろん、データは次のページに進む前に有効である必要があります。私の顧客は jQuery や Javascript を扱いたくないので、これは除外されます。この場合、検証を実装するための「ベスト プラクティス」とは何ですか?
Entity Framework 4 が使用されており、ほとんどの GUI コントロールは WebForms コントロールではなく HTML で実装されています。
私の顧客は jQuery och[sic] Javascript を扱いたくないので、これは除外されます。
良い。Javascript は、検証を強制するのに不適切な場所です。JavaScript で行う検証は、パフォーマンスの最適化にすぎません。データを真に検証できる場所は、サーバー上だけです。
.Net には、使用できるいくつかの便利な検証コントロールが含まれています。これらのコントロールの 1 つが CustomValidator です。これは非常に簡単にオーバーライドでき、独自のサーバー側コードを提供して、必要なルールを適用できます。Web フォームを使用している場合、これらのコントロールは当然の選択です。
複数ページのアプローチがあるため、Wizard コントロールを調べることもできます。
入力にカスタム HTML を使用している場合は、おそらく検証用にカスタム コードを使用する必要があります。サーバー側のフォーム ハンドラーでは、入力を検証し、何かが無効な場合にユーザーにページをレンダリングすることができます。入力チェックは次のように簡単です。
if (string.IsNullOrWhiteSpace(FormCollection["someRequiredInput"])
すべての入力を反復処理し、ビジネス ロジックに従ってチェックし、おそらくエラーのリストを作成できます。次に、入力チェックの後、エラーのリストが空でない場合は、何らかのプレースホルダーにエラーが追加されたページをユーザーにレンダリングします。リストが空の場合は、フォーム ポストの処理を続行します。
JavaScript が除外されなかったとしても、サーバー側の検証を実行する必要があります。 クライアント側のコードが意図したとおりに機能した、またはまったく実行されたとは決して想定しないでください。クライアント側の検証はセキュリティ対策ではなく、ユーザー エクスペリエンスを向上させるだけです。サーバー側の検証は、唯一の実際の検証です。
(そのため、追加された UX タッチに対してクライアント側の検証を追加できる可能性があります。クライアントが実際に JavaScript を禁止している場合、クライアントはそれを認識せず、代わりにサーバー側の検証を使用するだけです。これは時々参照されます。ユーザーがクライアント側のテクノロジーを無効にした場合、UX の良さはわずかに劣りますが、Web アプリケーションが引き続き完全に機能するように設計する「グレースフル デグラデーション」と同様です。)