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

  • [アーティクル]

ヒント

このコンテンツは eBook の「コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャ」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。

PDF のダウンロード

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

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

クライアント側の検証は、ユーザーにとって非常に便利です。 他の方法では、検証エラーが返される可能性のあるサーバーへのラウンド トリップを待つために必要な時間を節約できます。 ビジネス的に表現すると、1 回だけ見ればわずかな時間でも、それが毎日何百回も積み重なると、膨大な時間、費用、フラストレーションになります。 簡単かつ迅速な検証は、ユーザーの作業をいっそう効率的にし、入力と出力の品質が向上します。

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

クライアント側の検証を使用する場合でも、サーバー API が攻撃ベクトルになる可能性があるため、サーバー コードに含まれるコマンドまたは入力 DTO を常に検証する必要があります。 通常、両方を実行するのが最善の方法です。なぜなら、クライアント アプリケーションがある場合、UX の観点から、事前対応型にして、ユーザーに無効な情報を入力させない方法が最善のためです。

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

クライアント側の検証の実装は、構築するクライアント アプリケーションの種類によって変わります。 実装は、検証対象のデータが、ほとんどのコードが .NET による Web MVC Web アプリケーションであるのか、検証が JavaScript または TypeScript でコーディングされている SPA Web アプリケーションであるのか、または Xamarin と C# でコーディングされているモバイル アプリであるのか、によって変わります。

その他の技術情報

Xamarin モバイル アプリの検証

ASP.NET Core アプリの検証

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

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

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

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

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

  • ほとんどの場合、クライアント側で冗長な検証を行うことをお勧めします。これは、アプリケーションを事前対応型にすることができるためです。

前へ次へ