次の方法で共有

クライアント側の検証 (プレゼンテーション レイヤーでの検証)

  • [アーティクル]

ヒント

このコンテンツは、.NET Docs で入手できる、またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できる、コンテナー化された .NET アプリケーションの電子ブックである .NET マイクロサービス アーキテクチャからの抜粋です。

PDF のダウンロード

コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャの電子ブックの表紙サムネイル。

信頼できるソースがドメイン モデルであり、最終的にはドメイン モデル レベルで検証が必要な場合でも、ドメイン モデル レベル (サーバー側) と UI (クライアント側) の両方で検証を処理できます。

クライアント側の検証は、ユーザーにとって非常に便利です。 他の方法では、検証エラーが返される可能性のあるサーバーへのラウンド トリップを待つために必要な時間を節約できます。 ビジネス上、1 日に数百回乗算された数秒でも、多くの時間、費用、フラストレーションが発生します。 簡単で即時の検証により、ユーザーはより効率的に作業し、より良い品質の入力と出力を生成できます。

ビュー モデルとドメイン モデルが異なるのと同様に、ビュー モデルの検証とドメイン モデルの検証は似ていますが、目的は異なる場合があります。 DRY (Don't Repeat Yourself の原則) について心配している場合は、この場合、コードの再利用が結合を意味する可能性もあることを考慮してください。エンタープライズ アプリケーションでは、DRY 原則に従うよりも、サーバー側をクライアント側に結合しないことが重要です。

クライアント側の検証を使用する場合でも、サーバー API は攻撃ベクトルの可能性があるため、サーバー コードでコマンドまたは入力 DTO を常に検証する必要があります。 通常、クライアント アプリケーションがある場合は、UX の観点からプロアクティブにし、ユーザーが無効な情報を入力できないようにすることが最善であるため、両方を行うことをお勧めします。

そのため、クライアント側のコードでは、通常、ViewModel を検証します。 サービスに送信する前に、クライアント出力 DTO またはコマンドを検証することもできます。

クライアント側検証の実装は、構築しているクライアント アプリケーションの種類によって異なります。 .NET のほとんどのコードを使用して MVC Web アプリケーションのデータを検証する場合と、JavaScript または TypeScript の検証コードを使用した SPA Web アプリケーションの場合は異なります。

その他のリソース

ASP.NET Core アプリでの検証

SPA Web アプリでの検証 (Angular 2、TypeScript、JavaScript、Blazor WebAssembly)

要約すると、検証に関して最も重要な概念は次のとおりです。

  • エンティティと集計は、独自の整合性を強制し、"常に有効" にする必要があります。 集計ルートが、同じ集計内の複数エンティティの一貫性を担います。

  • エンティティが無効な状態になる必要があると思われる場合は、別のオブジェクト モデルを使用することを検討してください。たとえば、最終的なドメイン エンティティを作成するまで一時的な DTO を使用することを検討してください。

  • 集計などの複数の関連オブジェクトを作成する必要があり、それらすべてが作成された後にのみ有効な場合は、Factory パターンの使用を検討してください。

  • ほとんどの場合、アプリケーションをプロアクティブにできるため、クライアント側で冗長な検証を行うのが適切です。

前の次の